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ABSTRACT 


The quality of software management in a development project is a major 
factor in determining the success of a project. The four main areas in which a 
software project manager can affect the outcome of a project are people 
management, requirements management, estimation/planning management and 
risk management. People management is the management area with the highest 
influence on project success. 

In this thesis a quality management metric (QMM) was evaluated with 
respect to its conformance with an established people capability maturity model 
(P-CMM). The survey elements of the QMM were mapped to the processes 
described in the maturity model. The analysis indicates a high level of 
conformance of the QMM with the P-CMM. The results of applying the QMM can 
be used to characterize the quality of software management. Based on the 
correlation of QMM survey elements to processes of the maturity model, the 
results can then be used to identify processes that need improvement to increase 
the likelihood of program success. 

Future work includes further refining and assessing the QMM. As new 
models in the field of software development management evolve, the QMM will 
need to be re-evaluated with respect to these new models. 
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EXECUTIVE SUMMARY 


The quality of software management in a development project is a major 
factor in determining the success of a project. The four main areas in which a 
software project manager can affect the outcome of a project are people 
management, requirements management, estimation/planning management and 
risk management. People management is the management area with the highest 
influence on project success. 

In this thesis a quality management metric (QMM) was evaluated with 
respect to its conformance with an established people capability maturity model 
(P-CMM). The survey elements of the QMM were mapped to the processes 
described in the maturity model. The analysis indicates a high level of 
conformance of the QMM with the P-CMM except for objective - and purpose - 
related differences. The QMM questionnaire covers all processes of the P-CMM 
with relevancy for project management and is applicable as a quantitative 
performance measurement tool. 

The results of applying the QMM can be used to characterize the quality of 
software management. Based on the correlation of QMM survey elements to 
processes of the maturity model, the results can then be used to identify 
processes that need improvement to increase the likelihood of program success. 

Future work includes further refining and assessing the QMM. As new 
models in the field of software development management evolve, the QMM will 
need to be re-evaluated with respect to these new models. 
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I. INTRODUCTION AND BACKGROUND 


A. PROBLEM STATEMENT 

Software has grown tremendously important over the past decades. 
Information technology is present in almost all technical systems, and the 
capabilities, as well as properties, of technical systems are increasingly 
determined by software. A new technical system’s success depends increasingly 
on the development of appropriate software, which can be an extremely complex 
enterprising comprising millions of lines of code [GAO 93], 

Managing software development presents difficulties and risks beyond 
those found in the development of non-software products. Software is more 
complex per dollar spent than other engineering products [Osmundson 02b] and 
developmental problems cannot be treated, as would hardware manufacturing 
issues, because software, lacking a concrete existence, is not susceptible to 
physically testing or visual appraisal. Unlike hardware fabrication, which is based 
on blueprints, the task of implementing product specifications as software 
algorithms is a creative process continually in danger of misinterpretation. 
Because the flexible nature of software often allows changes throughout the 
developmental process, and, moreover, unforeseen difficulties may require 
deviations from the initial set of requested features, customers may be tempted 
to change their requirements as development progress—especially as they note 
discrepancies between their assumed expectations and the way they are 
interpreted and implemented. Managing software development commonly 
includes dealing with this phenomenon (known as “creeping requirements”) and 
the costs and scheduling fallout that may result. Requirement management, as 
well as estimation/planning and risk management, has to be an integral part of 
managing a software project. 

Software development is a creative act performed by educated 
professionals whose skill and performance may vary greatly. In general, the best 
performers will be about three times as productive as the average performer 
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[Osmundson 02b], To achieve maximum productivity, these developers deserve 
proper leadership to sustain motivation and inspiration. 

Though each programmer fulfills individual tasks, communication among 
the team is vital to successful development. Complex software requires intensive 
interaction between different program parts, requiring tight coordination in the 
work of individuals. Communication is also necessary between developer and 
customer to avoid misinterpretation of product requirements and assure that the 
final product is what the customer needs and wants. The program manager has 
to ensure proper communication within the development team and among all 
external stakeholders by ensuring effective people management, the aim of 
which is to allocate human resources appropriately, facilitate and institutionalize 
necessary communications, and provide leadership to the team. 

Successful development of software depends on numerous factors. 
Different development methods may be used and organization of the effort may 
take various forms. But while software-development methods have evolved over 
time in an attempt to enhance the prospects of project success, the results are 
still dissatisfying. More than fifty percent of software projects cost nearly ninety 
percent over their original estimates; the majority of software projects finish either 
over time or over budget [STSC 00, Osmundson 02a]; and about a third of all 
projects are cancelled [Osmundson 02b], The factor most affecting project failure 
is deficient management. Barry Boehm [Boehm 81] stated in 1981, 

Poor management can increase software costs more rapidly than 

any other factor. 

Twenty years later, this statement is still true. Poor management is seen 
as the primary cause of failure in the development of software-intensive systems 
[STSC 00], Shortfalls in people management pose severe project risks [Boehm 
87], and accordingly people management is seen as the most important part of 
software-development management [Chatzoglou 96, Machniak 99, Grossmann 
00 ], 
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To achieve success, software-development management must address 
four areas of focus: 

• Risk management 

• Requirements management 

• Estimation/planning management 

• People management 

Over the years, models have been built to describe how organizations 
deal with the task of software development. One dominant model is the Software 
Capability Maturity Model (SW-CMM) [PAULK 93], SW-CMM categorizes levels 
of maturity of development processes and describes associated abilities and 
tasks. Other models derived from the SW-CMM address integration or 
contracting aspects. But with people management most crucial to successful 
software-development, the People Capability Maturity Model (P-CMM) [Curtis 
01], which addresses the problems of managing an organization’s workforce, is 
of especial note. The P-CMM proposes specific practices and processes at 
differing maturity levels; at the predictable maturity level (level 4), measurement 
actions addressing quantitative performance management are proposed. 
However, the P-CMM does not provide specific metrics or tools. 

With management a dominant factor in the success of software 
development, obtaining an accurate evaluation of management quality is a key 
means of predicting project success. The results of such evaluations can be used 
to devise corrective actions, thus improving the probability of overall success and 
reducing the impact of adverse conditions and risks. 

The Ouality Management Metric (OMM) developed by Martin Machniak 

[Machniak 99] proposes a questionnaire for use in evaluating the quality of 

software-project management to improve performance. Much emphasis of the 

OMM centers on people management. Verification and validation of the OMM 

yields a positive correlation between a OMM score and overall program success 

[GROSSMANN 00], However, despite these encouraging results, the OMM has 

not been applied to projects other than those used for its verification and 

validation. A major reason is that the OMM concentrates on management areas 
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and processes and activities within these management areas, implementing 
various aspects looked at by the capability maturity models; but up to now it has 
lacked correlation to specific maturity levels. This leaves organizations and 
program managers doubtful whether it is applicable in their specific situation. 

The P-CMM, on the other hand, describes abilities required to perform 
activities at different maturity levels. Activities associated with a specific maturity 
level can be performed on lower maturity levels as well, but will be hampered by 
lack of underlying skills. Processes from a higher maturity level cannot reach 
their full potential until the proper foundation is laid [Paulk 93], The question 
arises whether the QMM can be used to measure people-management 
performance at the predictable maturity level of the P-CMM. To answer this 
question, the conformity of the QMM with the P-CMM must be analyzed. 

B. SOLUTION PATH 

The P-CMM [Curtis 01] serves as a model of best practices for managing 
an organization’s workforce. Quantitative performance management is described 
as a process area at the predictable maturity level, including the use of 
measurements to determine the status and performance of management 
activities. However, specific metrics or tools are not provided within the P-CMM. 

The QMM developed by Martin Machniak [Machniak 99] proposes a 
questionnaire that can be used to measure the quality of management of 
software-development projects and with that information to improve software- 
management performance. One of the areas addressed in the questionnaire is 
people management within the management of software development. 

The QMM therefore is a candidate for performing quantitative 
measurement of people management performance at the predictable maturity 
level of the P-CMM. It can be established as a metrics tool at this level if it 
conforms to the requirements on measurement raised at the predictable maturity 
level in the P-CMM. This needs to be analyzed and evaluated. 
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C. SCOPE OF THE RESEARCH 

The QMM covers management of requirements, estimation/planning, risk, 
and people. Of these, people management is seen as its most important 
component with the highest impact on success probability [Machniak 99], 

QMM Management Areas 



Figure 1. QMM Management Areas 
In view of that the people management area is also the one specifically 
addressed by a specific model (P-CMM) derived from the SW-CMM. This thesis 
will therefore focus on the people management aspect of the QMM. It will 
analyze the questionnaire’s conformity with quantitative-performance 
management measurements at the predictable maturity level in the P-CMM. 

D. ORGANIZATION 

Chapter II first discusses the QMM as an instrument for measuring 
software-management quality. Special emphasis is given to measuring people- 
management quality as an important component of software development 
management. It then discusses the P-CMM as a model of practices that improve 
the capabilities of an organization’s workforce. 


Chapter III compares the detail level and intents of the QMM questionnaire 
with the demands presented by the process goals on the different levels of the P- 
CMM. 
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Chapter IV presents an analysis of conformity and discrepancies between 
topics addressed by the QMM and the requirements for management of 
processes in the P-CMM. 

Chapter V presents conclusions from the analysis and recommendations 
for future work. 

E. BENEFITS 

The Department of Defense (DoD) is the world’s largest consumer of 
software goods and software-related services. Expenditures related to software 
exceed thirty billion dollar per year. The Software Technology Support Center 
states [STSC 00] 

Under austere budget constraints, DoD is using software as a force 
multiplier. Software increases the capabilities of warfighters by 
arming them with powerful, smart weapons and decision support 
tools. It gives them the flexibility to adjust to previously unknown 
threats. It allows them to do more with less; and it increases the 
effectiveness of our service men and women through information 
superiority. 

Successful software development is mandatory to achieve these 
accomplishments. But military software program failures still outnumber 
commercial software failures [STSC 00], 

This thesis will demonstrate the relevancy of the QMM-questionnaire as a 
measurement tool, as described above, and will show conformity and 
discrepancies between QMM and P-CMM. As a consequence it will show that the 
QMM-questionnaire is applicable as a quantitative performance measurement 
tool at the predictable maturity level of the P-CMM. The correlation of QMM and 
P-CMM will further allow program managers to use QMM results to identify 
deficient practices in project management. This will allow increasing the 
likelihood of success by changing and improving these practices, thus reducing 
the number of software development failures in DoD. 

The ultimate goal is to develop the QMM to a metrics tool that is in full 
conformance and fully correlated with relevant maturity models. 
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II. RELATED WORK 


A. QUALITY MANAGEMENT METRIC 

1. Background 

Development of software is regarded as successful if it 

• Delivers the product on time, 

• Stays within budget estimates, 

• Meets user requirements [Chatzoglou 96], 

To achieve success, software-development management must deal with 
four areas: estimation/planning, requirements, and people and risk management 
[Machniak 99], 

a. Estimation/Planning Management 

The purpose of estimation/planning management is to ensure that 
software is delivered on time and within budget. Empirical data have been used 
to identify key project attributes that affect cost and time of software 
development. Examples of these attributes are complexity, technical constraints, 
and capability and experience of personnel, and, as work progresses, the use of 
tools and observance of established practices. Project cost estimation models 
like the Constructive Cost Model (COCOMO) [Boehm 81] use these factors to 
estimate the size of the development effort. The impact of each attribute is 
calculated by using coefficients derived from empirical data, adjusted to the 
specifics of a given project to obtain more accurate predictions as a basis for 
planning. 

But as to a well-known dictum by 19 th -century Prussian strategist 
Helmuth von Moltke has it, 

No plan survives first contact with the enemy 

In software development, initial plans must be adjusted during 
development. Unforeseen difficulties in the creative process, discovery of 
unknowns, and changes in requirements and external constraints can and will 
have an impact on effort and schedule. Estimation/planning management has to 
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manage resulting changes to the plan and schedule to ensure successful 
software development. 

b. Requirement Management 

Estimation/planning management goes hand in hand with 
requirements management. Requirements are the initial reason for developing a 
software product. Customers formulate their expectations of software behavior 
and features through a list of requirements, and the success of a development 
effort is measured by how well the software conforms to stated requirements. 
Customers, however, do not provide specific direction as to implementation; their 
wishes must be interpreted by programmers as they are implemented in code. 
Requirement managers ensure that the initial set of requirements is of sufficient 
completeness and quality that misinterpretations are avoided and the product 
meets the customer’s specifications. 

The flexible nature of software often allows changes throughout the 
development process. Changes can result from unforeseen difficulties or from 
customers who are tempted to change their requirements as development 
progresses, based on external influences or perceived discrepancies between 
their own expectations and the way the requirements are actually interpreted and 
implemented. Requirement management has to anticipate these changes, both 
to control their influence and to coordinate resulting effects with 
estimation/planning management. 

c. People Management 

Software development is a creative act performed by educated 
professionals. If a product is built by a single person, there is no need for people 
management [Machniak 99], but in professional projects there is usually more 
than one person engaged. With the size and complexity of today’s software, the 
number of people involved in the typical project has also grown. These people 
need to be recruited, trained, organized and allocated to specific tasks to provide 
the human resources required for development. People managers must bear in 
mind that not only will the skill and performance of individual developers vary, but 
also the technical competence of the program manager. It is practically 
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impossible to staff a project with only top people. The allocation of tasks and 
assembly of teams must be optimized according to the available mix of 
personnel. 

Software developers require proper leadership to sustain 
motivation, inspiration, and satisfaction in their creative work. Job satisfaction 
and individual productivity are influenced mainly by the micro work environment. 
Likert identifies four distinct leadership philosophies leading to distinguishable 
micro work environments: exploitative autocratic, benevolent autocratic, 
consultative and participative [Likert 67], Leaders following a consultative or 
participative philosophy are seen as beneficial in creating a positive work 
environment. Leaders must also reinforce positive behavior and eliminate 
negative behavior (“reinforcement for performance”) to achieve maximum 
productivity. 

People management also addresses the communicative aspects of 
software development. External communication with the customer is a highly 
valuable means of avoiding misinterpretation of requirements. Internally, project 
goals, standards and specific procedures have to be mediated to achieve a 
common understanding among all personnel participating in the project. The 
goal is to establish and maintain effective internal horizontal communication 
between teams or among team members and vertical communication between 
team members and program management. Open lines of vertical and horizontal 
communication are crucial in achieving an encouraging working climate. It is rare 
to find an experienced program manager with comprehensive technical 
competence for every project. Open vertical communication enhances an 
inexperienced program manager’s ability to detect upcoming difficulties in time 
for appropriate action, thereby reducing the risk of unwanted fallout. 

d. Risk Management 

Risk management is the management aspect that identifies, 
mitigates, and eliminates potential problems with an aim toward minimizing harm 
to the overall effort. It is concerned with anticipating the outcome of future events, 
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and dealing with uncertainties and unforeseen consequences. The Defense 
Acquisition University defines risk [DAU 03] as: 

Risk is a measure of the inability to achieve overall program 
objectives within defined cost, schedule, and technical constraints 
and has two components: 

(1) the probability of failing to achieve a particular outcome and 

(2) the consequences/impacts of failing to achieve that 
outcome. 

Risks arise not only from technical difficulties, but from problems in 
other management areas as well, because likely problems in these areas fall 
under the purview of risk management. As appropriate mitigation or elimination 
strategies are enacted, managerial responses occur in the other areas; because 
risk management often counters problems in one management area by taking 
steps in another area (e.g., effects resulting from work delays are eliminated by 
actions within people management), risk management is treated as a distinct 
management field. 

2. Quality of Management 

Software-development methods have evolved over time in an attempt to 
enhance the prospects of project success. Numerous guides and manuals on 
risk management are available to provide assistance. Cost estimation methods 
have been refined to allow better estimates, and various tools support scheduling 
and planning. Despite all this, the results are far from satisfactory. More than fifty 
percent of software projects cost nearly ninety percent over their original 
estimates and the vast majority of software projects finish either over time or over 
budget [Osmundson 02a], With regard to these results, cost estimation models 
have only limited accuracy; the intermediate COCOM model, for instance, can 
estimate within a factor of about two [Osmundson 02b], 

One major reason for this inaccuracy results from the fact that quality of 
management is not taken into account by cost estimation models like COCOMO, 
disregarding the fact that the factor most implicated in project failure is deficient 
management. Poor management can increase software costs faster than any 
other factor and is the primary cause of failure in software development. 
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Implementing an input factor reflecting the quality of management into current 
cost and schedule estimators would increase the accuracy of these models; a 
metric instrument for quality management will provide such an input factor. 
Measuring the quality of software development management and comparing 
results against those achieved under management with a set of best practices 
will also allow identification of deficiencies and suggest corrective actions. 

3. Development of the QMM 

Martin Machniak [Machniak 99] developed a metric in form of a survey to 
assess the quality of software-development management in a software 
development program. The survey is conducted as a questionnaire in four parts, 
divided into two sections. Each part addresses one of the software development 
management areas, that is, requirements, estimation/planning, people, and risk. 

The questions posed are derived from research into recommended and 
successful practices, interviews with senior program managers and focus-group 
meetings. Questions in section one are pair-choice questions based on the 
Myers-Briggs Type Indicator (MBTI) [Briggs 93] questionnaire model. The 
questions require the participants to choose between two statements that present 
different ideas. The questions in section one detect consensus on issues and 
measure the strength of tendencies. Questions in section two are yes - no - not 
applicable (n/a) questions, a format chosen to standardize the answers for easy 
comparison. The questions in section two further evaluate the specific 
characteristics of the project and its management. The complete questionnaire 
contains 457 questions; each possible response is assigned a point value, which 
is not given to the project manager under examination. 

The point totals of both sections are added together to determine the total 
points for each management area. The totals of each management area are 
then multiplied by a relative importance coefficient (1C) to receive a weighted 
score. The 1C was determined to represent the relative importance of each of the 
management areas and their influence on the overall success of a software 
development project, based on actual experience. The weighted scores of the 
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four management areas are than added together to yield the Quality 
Management Metric (QMM) score. The QMM equation is as follows: 

QMM = 1.86 PM + 0.92 RqM + 0.67 EPM + 0.55 RkM 

PM is the people-management metric. It is assigned the highest 
importance coefficient, according to its importance in software-development. 
RqM is the requirements-management metric; EPM is the estimation/planning- 
management metric and RkM stands for the risk-management metric. 

Martin Machniak performed a test and an initial validation of the QMM with 
three software development programs [Machniak 99], Mary Grossmann 
continued this work and performed an informal verification and validation of the 
metric with another ten software development programs [Grossmann 00], Both 
studies yielded positive correlation between the results of the QMM and the 
overall success score. Mary Grossmann states consequently [Grossmann 00]: 

The results of applying the QMM can be used to characterize the 

quality of software management and can serve as a template to 

improve software management performance. 

4. Questions of the QMM 

a. Estimation/Planning Management 

Planning is one of the core tasks of management. It is based on 
estimation of three major program measures: products, processes, and 
resources [Pressman 93], Product measures address the volume of products 
produced. Process measures quantify behavior, development and problem¬ 
solving strategies, and execution of the process used to develop the products. 
Event counts (i.e., number of requirement changes) and time measures are 
included in process measures. Resource measures address the resources (e.g., 
labor hours, tools etc.) and their proper allocation to tasks. 

Accurate initial estimation of these measures will allow realistic 
planning of schedules and costs. As changes occur during the program, the 
program manager tracks product, process, and resource measures and makes 
necessary adjustments to the planning. The questions of the estimation/planning 
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part of the QMM questionnaire target the quality of estimation and planning. They 
determine whether initial and follow-up estimation and planning is conducted and 
documented, and whether this occurs using accepted software management 
methods and practices. 

b. Requirement Management 

One mark of successful software development is that the product 
meets customer expectations. The program manager has to establish 
procedures to define these expectations and to translate them into requirements 
that are complete, consistent, readable, unambiguous and testable. Test 
strategies and procedures have to be installed to verify conformity of the product 
with the extracted requirements. It is imperative to involve all stakeholders in the 
process of requirement extraction, as the requirements serve both as the source 
of feature implementation and (usually) as the contractual basis for development. 
Agreeing carefully on features is a means of identifying and communicating 
constraints on both sides and clarifying implementation priorities. 

Despite the flexible nature of software, requirement changes can 
have an enormous impact on schedule and costs of software development, 
especially if they occur late in the development process [Humphrey 95], 
Procedures for change control and management should be an integral part of 
requirement management. 

The questions of the QMM questionnaire evaluate the program on 
established procedures in requirements management. The areas addressed are 
requirement extraction, testability, and change management. 

c. People Management 

Because people management is the most important part of 
software-development management, it is assigned the highest importance 
coefficient (1C) value in the QMM equation. How management recruits, organizes 
and treats human resources is crucial to the success of a development program 
[Pressman 93], 
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The QMM questionnaire evaluates the three main areas of people 
management: handling of human resources, communication, and leadership. The 
hierarchy of factors and allocated sub factors is shown in Figure 2. 



Figure 2. People Management Areas (from [Machniak 99] 


The questions are designed to evaluate the program manager’s 

ability to: 

• Recruit, train and allocate human resources appropriately, 
including reinforcement and reward 

• Implement and sustain structures to facilitate vertical and 
horizontal communication, both within and without the 
program under evaluation 

• Provide leadership to the program and associated 
personnel, including evaluation of skills and competency of 
the program manager 

The questions do not attempt to type the program manager. 
However, as leadership following a consultative or participative philosophy is 
seen as beneficial to a positive work environment, scoring rewards 
commensurate behavior. 

d. Risk Management 

Risk is inherent to any development program. Risky areas in 
software development include software, hardware, technology, cost, schedule, 
and people. Risk management is the management aspect that identifies, 
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mitigates and eliminates potential problems to minimize induced negative effects 
on program success, and consists of two steps, risk assessment and control. 
Risk assessment is the task of identifying, analyzing and prioritizing risks as an 
ongoing task as changes occur. Risk control involves risk management, 
resolution and monitoring [Osmundson 02b], 

The QMM examines the quality of risk management by looking at 
the components of risk management, assessment and control. The questions 
evaluate whether the program manager has set up strategies, structures, and 
procedures to thoroughly implement these components in the program. 


B. PEOPLE CAPABILITY MATURITY MODEL 

1. Background 

New methodologies in the quest for consistent software-project success 
have been devised over the years, but none has proven adequate to the task. 
Nevertheless, it is well demonstrated that deficient management is a fundamental 
problem and the factor most likely to spell project failure [OUSDA 87], 

In 1986, in response to a request by the U.S. government, the Software 
Engineering Institute (SEI) started developing a model of a process maturity 
framework to help software developers improve their processes. The SW-CMM 
categorizes five levels of maturity of development processes and describes 
associated abilities and management and development practices. SW-CMM 
provides organizations with guidance on process assessments, software- 
capability evaluations, and process-improvement steps. After the release of an 
initial version in 1991, a reviewed version of the Capability Maturity Model for 
Software (SW-CMM v.1.1) was released in 1993 [Paulk 93], Since then, this 
model has been widely accepted and adopted in the commercial software- 
development industry. 

As previously noted, software development is a process highly dependent 
on the quality of the individuals involved. Dave Ulrich, named by the magazine 
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Business Week [BW 01] as the world’s top educator in human resources, states 
[Ulrich 97]: 

Successful firms will be those most adept at attracting, developing 
and retaining individuals with the skills, perspectives, and 
experience necessary to drive a global business. 

A shortage of experienced software professionals in the 1990s caused 
problems for organizations attempting to build and retain a skilled workforce. 
Personnel shortfalls lead to equal project risks. Positive experience with the SW- 
CMM led to requests for a derived model for improving workforce practices. The 
first version of the People Capability Maturity Model (P-CMM) was developed 
and released 1995 in response to these requests. Version 2.0 [Curtis 01] was 
released in 2001, adding enhancements learned from five years of 
implementation experience. 

2. Overview 

Capability maturity models describe the span of implementation of 
processes and practices within an organization. Processes and practices are 
allocated to different maturity levels, which represent different levels of 
organizational capability. The existing capability maturity models describe five 
levels of maturity. The maturity levels of the P-CMM range from the initial level 
providing minimal organizational capabilities, up to an optimized level with 
maximum organizational capabilities. Figure 3. shows the five maturity levels of 
the P-CMM. 
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Figure 3. Maturity Levels of the People CMM (from: [Curtis 01]) 


Each maturity level contains several process areas. Practices are 
allocated to a maturity level to achieve process-area goals. Figure 4. shows the 
architecture of the P-CMM. Notably the implementation of practices is not a 
component of the P-CMM. 
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Figure 4. Architecture of the People CMM (from: [Curtis 01]) 


3. Maturity levels of the P-CMM 

a. Level 1: Initial 

The initial level is the lowest in the people-capability maturity 
model. An organization at the initial level will exhibit the least organizational 
capabilities, as no specific process areas are developed. Management of the 
workforce and workforce practices are often ad hoc and inconsistent. 
Organizations at the initial level are characterized by 

• Inconsistency in practices 

• Displacement of responsibility 

• Ritualistic practices, and 

• Emotional detachment among the workforce. 

b. Level 2: Managed 

Processes at the second level focus on establishing a foundation of 
basic workforce practices at the unit level. The goals are to eliminate work- 
environment problems that hamper work at the unit level and to establish a 
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foundation for continuous development and improvement of workforce 
capabilities. Repeatable basic practices for managing the workforce are 
established and managers are assigned to accept responsibility for performance 
and personnel development in their units. 

Performance management is introduced on the managed level. Its 
purpose is to establish objectives against which unit and individual performance 
can be compared. 

Process areas at the managed level are 

• Staffing 

• Communication and coordination, 

• Work environment 

• Performance management 

• Training and development 

• Compensation 

c. Level 3: Defined 

Basic workforce practices on unit level have been established on 
maturity level two. On level three, organizations identify process abilities, 
knowledge and skills that are required to perform business activities. 
Competencies are fostered, matured, and aligned corporation-wide. The 
capability to manage a workforce as a strategic asset is developed. 

A participatory culture is established to ensure the flow of 
information within the organization and to incorporate the knowledge of 
individuals into decision-making. 

Process areas at the defined level are 

• Competency analysis 

• Workforce planning 

• Competency development 

• Career development 

• Competency-based practices 

• Workgroup development 
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• Participatory Culture 

d. Level 4: Predictable 

Organizations at maturity-level four quantify and manage the 
capability of their workforce and their competency-based processes. The 
quantification allows for the evaluation of trends in the capability of the 
organization and its elements. Organizations execute quantitative performance 
management to predict and manage the capability of competency-based 
processes. Performance data are collected and analyzed and these evaluated 
performance data are used as process-performance baselines in planning 
processes. Corrective actions are taken when actual performance differs from 
objectives and predictions. 

“In an immature organization, there is no objective basis for judging 
product quality or for solving product or process problems. Therefore, product 
quality is difficult to predict” [SW-CMM] 

Another key idea at the predictable level is the building of 
empowered teams that are able to manage their own work processes. The idea 
is to build teams so that the different skills and experience of individuals 
complement each other. 

Process areas at the defined level are 

• Competency integration 

• Empowered workgroups 

• Competency-based assets 

• Quantitative performance management 

• Organizational capability management 

• Mentoring 

e. Level 5: Optimizing 

Process areas are fully developed at the optimizing level. 
Organizations are continually applying methods for developing competence on 
the individual, unit, and organizational level and try to further improve their 
methods. The effectiveness of workforce practices is analyzed and new 
technologies and practices are evaluated. Successful elements are implemented 
for further use. 
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Process areas at the defined level are 

• Continuous capability improvement 

• Organizational performance alignment 

• Continuous workforce innovation 
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III. COMPARISON OF QMM AND P-CMM 


A. COMPARABLE LEVEL OF DETAIL 

1. QMM 

A management survey instrument in form of a questionnaire has to be 
manageable, usable and applicable for a broad range of projects. This limits the 
number of questions and the level of detail a questionnaire can contain. The 
QMM questionnaire overall contains 457 questions, resulting in a reasonable 
average survey-completion time of 45 minutes. One hundred and eighteen 
questions, divided in two sections, address people management. This number is 
sufficient to evaluate relevant management ideas but restricts the level of detail 
at which practices to implement those ideas can be evaluated. 

The questions in section one that pertain to people management are 
designed to detect consensus on issues and ideas, but not to address specific 
implementations of these ideas. For instance, one question asks whether 
management leads problem solving or whether management merely facilitates, 
letting the team leader act. Another question address the participatory culture by 
asking whether the relationship between the team and manager is of an 
adult/adult or parent/child type. Both cases evaluate to what degree the specific 
idea or goal under investigation is strived for, but do not examine the specific 
implementation. 

In section two, questions are yes-no-n/a queries that address goals of 
processes and practices, but, again, do not address implementation. For 
example, whether the program manager facilitates communication during 
integration is asked, but as implementation will depend on the characteristics of a 
specific project or organization, it is not covered. 

Thus, the QMM questionnaire does not question every implementation 
detail but remains at a reasonable abstraction level and examines whether, in a 
given project, good management goals are pursued and implemented. This 
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approach allows projects to choose different implementations of goals and 
practices without negative impact on the QMM score. 

The project manager will often be limited by external constraints in his 
goals and practices. The n/a selection in section two of each management area 
allows the test to consider constraints. The questions are designed so that the 
QMM score is unaffected by constraints. 

2. P-CMM 

Starting with the second level, three-to-five process areas are associated 
with each maturity level, for a total of twenty-two. Process areas represent a set 
of interrelated practices that together enable an organization or unit to achieve 
the capabilities related to the specific maturity level. For each process area, 
goals are described that an organization or unit that describe what must be 
implemented to satisfy the purpose of the process area (see Figure 4 for a 
description of the P-CMM architecture). 

In a next step a set of practices is described for each process area. The 
practices contribute to the goals of the process area. A mapping of practices to 
goals is conducted in annex D of [Curtis 01]. However, the P-CMM states [Curtis 
01 ]: 

These practices have been selected for inclusion because they 
contribute to satisfying process area goals. However, they are 
neither an exclusive or exhaustive list of practices an organization 
might implement in pursuing the goals of a process area. 

And furthermore [Curtis 01]: 

Similarly, when assessing or evaluating alternative ways to 
implement a process area, the goals can be used to determine if 
the alternative practices satisfy the intent of the process area. 

This allows organizations to implement practices differing from those 
named in the P-CMM as long as these practices are able to pursue the goals of 
the respective process area. In conclusion, process goals associated with the 
process areas are reasonable candidates in the P-CMM for a comparison of P- 
CMM compliance of the QMM. 
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The P-CMM addresses the development of the capabilities of an 
organization as a whole. The listed process areas deal with four areas of 
concern: 


• Developing individual capability 

• Building workgroups and culture 

• Motivating and managing performance 

• Shaping the workforce 

Thus the process areas and derived goals of the P-CMM deal with 
processes and practices on the individual, on the unit and on the organizational 
level. A survey of the quality of management in a specific project has to take into 
account practices influencing the individual person or the specific unit and under 
survey. Practices targeting the organization or its capabilities as a whole, e.g. 
whether an organization tracks its capabilities of its workforce competencies, are 
neither the subject of management activities of a project management nor do 
they have direct impact on the success of a project. For this reason the process 
goals of the P-CMM are examined to determine the goals relevant for a 
comparison with the QMM. 


B. PROCESS GOALS OF P-CMM 

1. General 

Process areas organize interrelated practices and constitute major 
organizational processes. They are described by their purpose and associated 
goals. Based on the descriptions in [Curtis 01], following these process goals are 
examined to determine which process goals are relevant for a comparison with 
the QMM. A process goal is relevant for a comparison if it either addresses 
practices and activities performed by the project management or if it has direct 
influence on the activities and individuals in a project. 

2. Process Areas at Level 2 
a. Staffing 
Purpose / goals [Curtis 01]: 
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The purpose of staffing is to establish a formal process by 
which committed work is matched to unit resources and qualified 
individuals are recruited, selected, and transitioned into 
assignments. 

• Goal 2.a.1: Individuals or workgroups in each unit are involved in 
making commitments that balance the unit’s workload with 
approved staffing. 

• Goal 2.a.2: Candidates are recruited for open positions 

• Goal 2.a.3: Staffing decisions and work assignments are based on 
an assessment of work qualifications and other valid criteria 

• Goal 2.a.4: Individuals are transitioned into and out of positions in 
an orderly way. 

• Goal 2.a.5: Staffing practices are institutionalized to ensure they 
are performed as managed processes. 

Software development is a creative act performed by educated 
professionals. Software projects need to be staffed adequately to be able to 
perform software development. While as a practical matter it is impossible to staff 
a project with only top people, allocation of tasks and team assembly must be 
optimized according to the available personnel. Therefore, staffing with all listed 
goals (2.a.1 - 2.a.5) is a process area relevant for project management and a 
comparison with the QMM. 

b. Communication and Coordination 
Purpose / goals [Curtis 01]: 

The purpose of Communication and Coordination is to 
establish timely communication across the organization and to 
ensure that the workforce has the skills to share information and 
coordinate their activities efficiently. 

• Goal 2.b.1: Information is shared across the organization 

• Goal 2.b.2: Individuals or groups are able to raise concerns and 
have them addressed by management 

• Goal 2.b.3: Individuals and workgroups coordinate their activities to 
accomplish committed work 

• Goal 2.b.4: Communication and Coordination practices are 
institutionalized to ensure they are performed as managed 
processes 
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Communication is a key in software development; it is crucial to 
coordinate the work of developers fulfilling individual tasks and to notify the 
management about problems and deviations from plans. Communication is also 
necessary between developer and customer to avoid misinterpretation of product 
requirements. Communication and coordination with all associated goals (2.b.1 - 
2.b.4) is a process area relevant for project management and a comparison with 
the QMM. 


c. Work Environment 

Purpose / goals [Curtis 01]: 

The purpose of Work Environment is to establish and 
maintain physical working conditions and to provide resources that 
allow individuals and workgroups to perform their tasks efficiently 
and without unnecessary distractions. 

• Goal 2.C.1 : The physical environment and resources needed by the 
workforce to perform their assignments are made available. 

• Goal 2.C.2: Distractions in the work environment are minimized. 

• Goal 2.C.3: Work Environment practices are institutionalized to 
ensure they are performed as managed processes. 

A proper work environment is required to be able to perform 

development activities. One might argue that the organization is responsible for 

providing required resources to the project as a whole. Nevertheless, it is the 

responsibility of the program manager to ensure that within his project the 

environment and resources required to perform the work are available. It is also 

his responsibility to identify and address factors that degrade effectiveness. The 

process area of work environment, with all associated goals (2.C.1 - 2.C.3), is 

relevant for project management and a comparison with the QMM. 

d. Performance Management 
Purpose / goals [Curtis 01] 

The purpose of Performance Management is to establish 
objectives related to committed work against which unit and 
individual performance can be measured, to discuss performance 
against these objectives, and to continuously enhance 
performance. 
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• Goal 2.d.1: Unit and individual performance objectives related to 
committed work are documented. 

• Goal 2.d.2: The performance of committed work is regularly 
discussed to identify actions that can improve it. 

• Goal 2.d.3: Performance problems are managed. 

• Goal 2.d.4: Outstanding performance is recognized or rewarded. 

• Goal 2.d.5: Performance Management practices are 

institutionalized to ensure they are performed as managed 
processes. 

Software has to be delivered on time and within budget. Related 
planning and scheduling is based on expectations of work performed by units 
and individuals, i.e., performance objectives. Leaders must reinforce positive 
behavior and eliminate negative behavior (“reinforcement for performance”) to 
achieve maximum productivity. Performance management, with all associated 
goals (2.d.1 - 2.d.5), is a process area relevant for project management and a 
comparison with the QMM. 

e. Training and development 
Purpose / goals [Curtis 01]: 

The purpose of Training and Development is to ensure that 

all individuals have the skills required to perform their assignments 

and are provided relevant development opportunities. 

• Goal 2.e.1: Individuals receive timely training that is needed to 
perform their assignments in accordance with the unit’s training 
plan 

• Goal 2.e.2: Individuals capable of performing their assignments 
pursue development opportunities that support their development 
objectives 

• Goal 2.e.3: Training and Development practices are 
institutionalized to ensure they are performed as managed 
processes. 

Training is a means that project management can use to equip 
workers to perform their assignments. The training aspect with related goals 
(2.e.1, 2.e.3) is relevant for project management and a comparison with the 
QMM. 
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The project mangers will identify individuals capable of performing 
assignments as part of performance-management processes (III.B.2.d). A 
project’s internal management activities are covered by performance 
management (III.B.2.d) and compensation processes (III.B.2.f). Information about 
outstanding performance may also be passed to other parts of the organization 
as part of their effort to give recognition as appropriate. Providing opportunities to 
pursue advanced development, however, will exceed the scope of a project and 
its management, as it is not justified by project needs. Goal 2.e.2 therefore is not 
a candidate for comparison with the QMM. 
f. Compensation 
Purpose / goals [Curtis 01]: 

The purpose of Compensation is to provide all individuals 

with remuneration and benefits based on their contribution and 

value to the organization. 

• Goal 2.f.1: Compensation strategies and activities are planned, 
executed, and communicated 

• Goal 2.f.2: Compensation is equitable relative to skill, qualifications 
and performance 

• Goal 2.f.3: Adjustments in compensation are made based on 
defined criteria 

• Goal 2.f.4: Compensation practices are institutionalized to ensure 
they are performed as managed processes. 

A compensation strategy is developed on the organizational level. 
Though compensation is interwoven with staffing (III.B. 1 .a) which is a 
responsibility of project management, compensation is normally determined by 
organizational regulations, e.g. in government [Machniak 99], The program 
manager is only able to arrange an equitable compensation relative to skill, 
qualifications and performance within the limits of these regulations. 
Compensation with its associated goals (2.f.1 - 2.f.4) as a process area that 
addresses actions on the organizational level therefore is not a candidate for a 
comparison with the QMM. 

3. Process Areas at Level 3 

a. Competency Analysis 
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Purpose / goals [Curtis 01]: 


The purpose of Competency Analysis is to identify the 
knowledge, skills, and process abilities required to perform the 
organization’s business activities so that they may be developed 
and used as a basis for workforce practices. 

• Goal 3.a.1: The workforce competencies required to perform the 
organization’s business activities are defined and updated 

• Goal 3.a.2: The work processes used within each workforce 
competency are established and maintained 

• Goal 3.a.3: The organization tracks its capability in each of its 
workforce competencies 

• Goal 3.a.4: Competency Analysis practices are institutionalized to 
ensure they are performed as defined organizational processes. 

The ability to perform software development as a business requires 

certain workforce competencies. These competencies need to be identified and 

defined; underlying competency-based processes need to be established. While 

one might argue that this task is primarily important on the organizational level, it 

also has relevancy on the project management level. 

Even if information on competencies is delivered and processes are 
established at the organizational level, project specifics still may require 
deviations. The project management has to identify required competencies 
specific for its software development project as a basis for recruiting and training. 
Competency-based processes need to be established on the project level and 
tailored to specific project needs. Tracking of project-team capabilities is part of 
project control and supervision. Competency analysis—with its scope including 
project specific competencies and processes—with all associated goals (3.a.1 - 
3.a.4) is a process area relevant for project management and a comparison with 
the QMM. 


b. Workforce Planning 

Purpose / goals [Curtis 01]: 

The purpose of Workforce Planning is to coordinate 
workforce activities with current and future business needs at both 
the organizational and unit levels. 
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• Goal 3.b.1: Measurable objectives for capability in each of the 
organizations workforce competencies are defined 

• Goal 3.b.2: The organization plans for the workforce competencies 
needed to perform its current and future business activities 

• Goal 3.b.3: Units perform workforce activities to satisfy current and 
strategic competency needs 

• Goal 3.b.4: Workforce Planning practices are institutionalized to 
ensure they are performed as defined organizational processes. 

On the organizational level, workforce activities are tied to an 

organization’s business strategy and objectives as a basis for strategic planning. 

Project management will not conduct activities on this level. Goals 3.b.1 and 

3.b.2 therefore are not candidates for a comparison with the QMM. 

Management has to perform planning activities to satisfy current 
and future competency needs. Workforce activities at the unit level—i.e., the 
level of an individual project—are explicitly addressed by goal 3.b.3. Workforce 
planning with its associated goals 3.b.3 and 3.b.4 is a process area that is partly 
relevant for project management and comparison with the QMM. 
c. Competency Development 
Purpose / goals [Curtis 01]: 

The purpose of Competency Development is to constantly 

enhance the capability of the workforce to perform their assigned 

tasks and responsibilities. 

• Goal 3.C.1: The organization provides opportunities for individuals 
to develop their capabilities in its workforce competencies 

• Goal 3.C.2: Individuals develop their knowledge, skills, and process 
abilities in the organization’s workforce competencies 

• Goal 3.C.3: The organization uses the capabilities of its workforce 
as resources for developing the workforce competencies of others. 

• Goal 3.C.4: Competency Development practices are 
institutionalized to ensure they are performed as defined 
organizational processes. 

Competency development activities are intended to serve business 
objectives. They increase the individuals’ ability to work in their units and are 
meant to support their development objectives. Projects will benefit from these 
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processes and may even participate in related activities. Competency 
development, however, targets the business objectives of the organization, while 
project needs are addressed by other activities (e.g., training and development). 
The process area competency development and its associated goals therefore is 
not a candidate for a comparison with the QMM. 

d. Career Development 
Purpose / goals [Curtis 01]: 

The purpose of Career Development is to ensure that 
individuals are provided opportunities to develop workforce 
competencies that enable them to achieve career objectives. 

• Goal 3.d.1: The organization offers career opportunities that 
provide growth in its workforce competencies 

• Goal 3.d.2: Individuals pursue career opportunities that increase 
the value of their knowledge, skills, and process abilities to the 
organization. 

• Goal 3.d.3: Career Development practices are institutionalized to 
ensure they are performed as defined organizational processes. 

Career Development may target overarching career opportunities 

and objectives beyond the level of project management. The project 

management however is directly involved as career development depends on 

underlying activities in areas like performance management and competency 

development. Career Development activities of the program management also 

contribute to motivation and reinforcement for performance. The program 

manager has to be active in Career Development practices that require direct 

interaction with the individual like capability assessment and counseling, while 

offering of career opportunities and institutionalizing career development 

practices reside on the organizational level. Goal 3.d.2 therefore is a goal from 

the process area Career Development that is a candidate for a comparison with 

the QMM, while goals 3.d.1 and 3.d.3 are not candidates. 

e. Competency-Based Practices 
Purpose / goals [Curtis 01]: 
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The purpose of Competency-Based Practices is to ensure 

that all workforce practices are based in part on developing the 

competencies of the workforce. 

• Goal 3.e.1: Workforce practices are focused on increasing the 
organization’s capability in its workforce competencies 

• Goal 3.e.2: Workforce activities within units encourage and support 
individuals and workgroups in developing and applying the 
organization’s workforce competencies. 

• Goal 3.e.3: Compensation strategies and recognition and reward 
practices are designed to encourage development and application 
of the organization’s workforce competencies 

• Goal 3.e.4: Competency-based practices are institutionalized to 
ensure they are performed as defined organizational processes. 

In the process area of competency-based practices, processes and 

practices are adjusted and aligned throughout the organization to support its 

focus on developing workforce skills and to meet strategic goals. Goal 3.e.2 

addresses the impact on project management, as practices at the unit level must 

adjust to meet organizational strategic plans and objectives. Strategic plans and 

objectives will have an impact on project management in the form of directives or 

constraints which must be dealt with. The resulting activities, however, are 

following overarching purposes and not related to a specific project. The process 

area competency-based practices and its associated goals therefore are not 

candidates for a comparison with the QMM. 

f. Workgroup Development 

Purpose / goals [Curtis 01]: 

The purpose of Workgroup Development is to organize work 

around competency-based process abilities. 

• Goal 3.f.1: Workgroups are established to optimize the 
performance of interdependent work. 

• Goal 3.f.2: Workgroups tailor defined processes and roles for use in 
planning and performing their work. 

• Goal 3.f.3: Workgroup staffing activities focus on the assignment, 
development, and future deployment of the organization’s 
workforce competencies 
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• Goal 3.f.4: Workgroup performance is managed against 
documented objectives for committed work. 

• Goal 3.f.5: Workgroup Development practices are institutionalized 
to ensure they are performed as defined organizational processes. 

For a product built by a single person, there is no need for people 

management. With the size and complexity of today’s software, however, the 

number of people involved in the typical project has mushroomed. Software 

development as a business activity employing specific competency-based 

processes is performed by workgroups consisting of teams or individuals 

performing interdependent work. Workgroup development is a fundamental task 

of project management. The process area of workgroup development, with 

associated goals (3.f.1 - 3.f.5), is a process area relevant for project 

management. 

g. Participatory Culture 

Purpose / goals [Curtis 01]: 

The purpose of a Participatory Culture allows the 

organization to exploit the full capability of the workforce for making 

decisions that affect the performance of business activities. 

• Goal 3.g.1: Information about business activities and results is 
communicated throughout the organization 

• Goal 3.g.2: Decisions are delegated to an appropriate level of the 
organization 

• Goal 3.g.3: Individuals and workgroups participate in structured 
decision-making processes 

• Goal 3.g.4: Participatory Culture practices are institutionalized to 
ensure they are performed as defined organizational processes. 

The kind of leadership philosophy a leader demonstrates 

determines the micro work environment. Providing leadership is one of the 

fundamental tasks of a program manager. The process area of participatory 

culture, with its associated goals (3.g.1 - 3.g.4), is a relevant for project 

management and a comparison with the QMM. 

4. Process Areas at Level 4 

a. Competency Integration 
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Purpose / goals [Curtis 01]: 

The purpose of Competency Integration is to improve the 
efficiency and agility of interdependent work by integrating the 
process abilities of different workforce competencies. 

• Goal 4.a.1: The competency-based processes employed by 
different workforce competencies are integrated to improve the 
efficiency of interdependent work 

• Goal 4.a.2: Integrated competency-based processes are used in 
performing work that involves dependencies among several 
workforce competencies 

• Goal 4.a.3: Workforce practices are designed to support multi¬ 
disciplinary work 

• Goal 4.a.4: Competency Integration practices are institutionalized 
to ensure they are performed as defined organizational processes. 

Software development constitutes a specific distinguishable 

workforce competency. This process area, however, targets integration and 

coordination of separate workforce competencies, like market research, sales, 

and software development. Respective dependencies at the project management 

level are already covered in process areas such as communication and 

coordination. The process area competency-based practices and its associated 

goals are not candidates for a comparison with the QMM. 

b. Empowered Workgroups 

Purpose / goals [Curtis 01]: 

The purpose of Empowered Workgroups is to invest 
workgroups with the responsibility and authority for determining 
how to conduct their business activities most effectively. 

• Goal 4.b.1: Empowered workgroups are delegated responsibility 
and authority over their work processes. 

• Goal 4.b.2: The organization’s workforce practices and activities 
encourage and support the development and performance of 
empowered workgroups. 

• Goal 4.b.3: Empowered workgroups perform selected workforce 
practices internally 

• Goal 4.b.4: Empowered Workgroup practices are institutionalized to 
ensure they are performed as defined organizational processes. 
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An empowered workgroup describes a workgroup, unit, or unit 
component that is granted responsibility and authority for a whole work process 
[Wellins 91]. Empowered workgroups are able to act independently within the 
constraints of the overarching element. While the whole software-development 
team constitutes an empowered workgroup, the size and complexity of today’s 
software development efforts requires a breakdown of work efforts. This 
encourages building of responsible empowered workgroups within the project 
team. The process area of participatory culture, with its associated goals (4.b. 1 - 
4.b.4) is a process area relevant for project management and comparison with 
the QMM. 

c. Competency-Based Assets 

Purpose / goals [Curtis 01]: 

The purpose of Competency-Based Assets is to capture the 
knowledge, experience, and artifacts developed in performing 
competency-based processes for use in enhancing capability and 
performance. 

• Goal 4.C.1: The knowledge, experience, and artifacts resulting from 
performing competency-based processes are developed into 
competency-based assets 

• Goal 4.C.2: Competency-based assets are deployed and used. 

• Goal 4.C.3: Workforce practices and activities encourage and 
support the development and use of competency-based assets 

• Goal 4.C.4: Competency-based assets activities are institutionalized 
to ensure they are performed as defined organizational processes. 

Competency-based assets describe assets developed and 

provided at the organizational level for widespread use. These assets capture the 

knowledge, experience, or artifacts of competency-based processes and make 

them available. Software development projects will benefit from the existence of 

such assets, but for the scope of management such benefits are already dealt 

with as input in competency-analysis processes. Projects will also contribute to 

the development of competency-based assets. Associated activities, however, 

are not part of the software-development effort. The process area competency- 


36 



based assets and its associated goals are not candidates, therefore, for a 
comparison with the QMM. 

d. Quantitative Performance Management 

Purpose / goals [Curtis 01]: 

The purpose of Quantitative Performance Management is to 
predict and manage the capability of competency-based processes 
for achieving measurable performance objectives. 

• Goal 4.d.1: Measurable performance objectives are established for 
competency-based processes that most contribute to achieving 
performance objectives 

• Goal 4.d.2: The performance of competency-based processes is 
managed quantitatively 

• Goal 4.d.3: Quantitative Performance Management practices are 
institutionalized to ensure they are performed as defined 
organizational processes 

Predicting capabilities and managing performance form the basis of 
any scheduling and planning. Quantitative performance management is a 
necessary and fundamental task of project management. The process area 
quantitative performance management with all associated goals (4.d.1 -4.d.3), is 
therefore a process area relevant for project management and a comparison with 
the QMM. 


e. Organizational Capability Management 

Purpose / goals [Curtis 01]: 

The purpose of Organizational Capability Management is to 
quantify and manage the capability of the workforce and of the 
critical competency-based processes they perform. 

• Goal 4.e.1: Progress in developing the capability of critical 
workforce competencies is managed quantitatively 

• Goal 4.e.2: The impact of workforce practices and activities on 
progress in developing the capability of critical workforce 
competencies is evaluated and managed quantitatively 

• Goal 4.e.3: The capabilities of competency-based processes in 
critical workforce competencies are established and managed 
quantitatively 
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• Goal 4.e.4: The impact of workforce practices and activities on the 
capabilities of competency-based processes in critical workforce 
competencies is evaluated and managed quantitatively 

• Goal 4.e.5: Organizational Capability Management practices are 
institutionalized to ensure they are performed as defined 
organizational processes. 

Organizational-capability management targets the capabilities of 
the workforce as whole. Workforce competencies most critical for an 
organization’s business strategy and objectives are identified and their availability 
evaluated. Because the focus of these activities is beyond the level of project 
management, organizational-capability management and its associated goals are 
not candidates for a comparison with the QMM. 
f. Mentoring 
Purpose / goals [Curtis 01]: 

The purpose of Mentoring is to transfer the lessons of 
greater experience in a workforce competency to improve the 
capability of other individuals or workgroups. 

• Goal 4.f.1: Mentoring programs are established and maintained to 
accomplish defined objectives 

• Goal 4.f.2: Mentors provide guidance and support to individuals or 
workgroups 

• Goal 4.f.3: Mentoring practices are institutionalized to ensure they 
are performed as defined organizational processes. 

Mentoring addresses programs and activities at the organizational 

level. Projects benefit where mentoring and coaching are provided in an 

organized and structured form. Such activities at the project management level 

however are initiated as part of activities in the process area of training. The 

process area of mentoring and its associated goals are not candidates for a 

comparison with the QMM. 

5. Process Areas at Level 5 

a. Continuous Capability Improvement 

Purpose / goals [Curtis 01]: 

The purpose of Continuous Capability Improvement is to 
provide a foundation for individuals and workgroups to continuously 
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improve their capability for performing competency-based 
processes. 

• Goal 5.a.1: The organization establishes and maintains 
mechanisms for supporting continuous improvement of its 
competency-based processes. 

• Goal 5.a.2: Individuals continuously improve the capability of their 
personal work processes. 

• Goal 5.a.3: Workgroups continuously improve the capability of their 
workgroup’s operating processes. 

• Goal 5.a.4: The capabilities of competency-based processes are 
continuously improved. 

• Goal 5.a.5: Continuous Capability Improvement practices are 
institutionalized to ensure they are performed as defined 
organizational processes. 

The process area of continuous capability improvement addresses 
improvement at the organizational, unitary, and workgroup levels. Improvements 
on the organizational level (i.e., Goal 5.a.1) are beyond the scope of project 
management. Project management supports improvements for individuals (i.e., 
Goal 5.a.2) with activities from areas such as performance management, but the 
process itself is not part of project management. Project managers, however, 
should strive to improve of the capability of operating and competency processes 
and execute related practices. Continuous capability improvement, with its 
associated goals (5.a.3, 5.a.4 and 5.b.5), is a process area partly relevant to 
project management and comparison with the QMM. 

b. Organizational Performance Alignment 
Purpose / goals [Curtis 01]: 

The purpose of Organizational Performance Alignment is to 
enhance the alignment of performance results across individuals, 
workgroups and units with organizational performance and 
business objectives. 

• Goal 5.b.1: The alignment of performance among individuals, 
workgroups, units and the organization is continuously improved. 

• Goal 5.b.2: The impact of workforce practices and activities on 
aligning individual, workgroup, unit, and organizational performance 
is continuously improved. 
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• Goal 5.b.3: Organizational Performance Alignment practices are 
institutionalized to ensure they are performed as defined 
organizational processes 

Quantitative performance management delivers information about 
the performance of individuals and units. Reinforcement for good performance is 
a means of achieving maximum productivity, which includes aligning 
performance at the highest possible level. Organizational performance alignment, 
with associated goals (5.b.1 - 5.b.3) is therefore relevant for project management 
and comparison with the QMM. 

c. Continuous Workforce Innovation 
Purpose / goals [Curtis 01]: 

The purpose of Continuous Workforce Innovation is to 
identify and evaluate improved or innovative workforce practices 
and technologies, and implement the most promising ones 
throughout the organization. 

• Goal 5.C.1: The organization establishes and maintains 
mechanisms for supporting continuous improvement of its 
workforce practices and technologies. 

• Goal 5.C.2: Innovative or improved workforce practices and 

technologies are identified and evaluated. 

• Goal 5.C.3: Innovative or improved workforce practices and 

technologies are deployed using orderly procedures 

• Goal 5.C.4: Continuous Workforce Innovation practices are 

institutionalized to ensure they are performed as defined 
organizational practices. 

Software projects can take advantage of innovative and improved 
practices and technologies. New benefits, however, have to be considered 
against the risks and costs involved in changing to new technologies and 
practices. Goal 5.C.1 provides a framework that empowers workgroups and 
project managers to employ improvements. Goals 5.C.2 to 5.C.4 describe the 
practices related to improvement activities conducted by management. The 
process area continuous workforce innovation, with its associated goals (5.C.2, 
5.C.3 and 5.C.4) is relevant for project management and comparison with the 
QMM. 
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IV. ANALYSIS OF COMPLIANCE OF QMM WITH P-CMM 


A. GENERAL 

Relevant for an evaluation of the quality of management of a software 
development are process goals that target activities on the unit or workgroup 
level. Process goals targeting the organizational level may require inputs or 
corresponding activities by project management. These activities however are 
not related to a specific software development project and cannot be 
incorporated in measuring the quality of software development project 
management. 

The P-CMM lists twenty-two process areas on maturity levels two to five 
that contribute to the capabilities of the workforce of an organization. Each 
process area contains three to five goals stating the objective of the process 
area, adding up to a total number of ninety process goals. Chapter III identified 
fifty-one process goals from fifteen process areas that target practices and 
activities that not only have to be performed by project management but also are 
affect project’s success. The QMM has to address these project goals to be fully 
conformant with the P-CMM. 

Note that following the P-CMM does not involve ranking of process goals 
beside the allocation of processes to different maturity levels. The P-CMM also 
does not provide information about the impact the different processes have on 
the success of a software development project. It describes all processes with a 
uniform level of detail. The representation of processes - given by the number of 
questions and the level of detail - in the QMM however depends on the 
significance of the specific process for the project outcome. P-CMM processes 
therefore are represented in the QMM differently depending on the importance of 
the specific process for the project outcome. 

In each process area, there is one process goal that addresses whether 
the processes are institutionalized. This is done uniformly for all process areas to 
ensure that processes are performed as managed or defined organizational 
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processes. To fulfill these process goals, organizations are requested to 
establish and maintain documented policies for the respective activities, to assign 
responsibility and authority for performing activities and to review 
implementation. The implementation of a program manager role implies 
assignment of responsibility and authority. Policy establishment and review 
activities on the organizational level are not part of the project manager’s 
responsibilities and cannot be used to determine his quality of management. 
Institutionalization in the level of a unit is seen when practices are performed in a 
managed way and consistently. 

The QMM questions are portioned into the four management areas: 
people management, estimation/planning management, risk management, and 
requirements management. The P-CMM, as a self-contained model, also 
contains aspects that the QMM allocates to other management areas. The 
respective questions of other management areas in the QMM have been 
considered in the comparison to the P-CMM where applicable. 

B. COMPARISON MATRICES 

Appendix A contains the QMM questionnaire from [Machniak 99], 

Appendix B contains a complete comparison matrix. The matrix 
incorporates the questions of both sections of the people management part of the 
QMM. Questions of other management parts are added where applicable. 
Questions are numbered for better identification in the different evaluated 
matrices. 

Appendix C contains the evaluated comparison matrices. For each 
process area the process goals are listed, followed by an evaluated comparison 
matrix for this process area. The evaluated comparison matrix indicates 
association of questions to process goals. Where the wording of a question was 
not sufficient to identify underlying concepts, the concept descriptions from 
[Machniak 99] were consulted. For further characterization of process goals, the 
related example practices and descriptions from [Curtis 01] were consulted. 
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QMM questions not related to the goals of the specific process are removed from 
the evaluated comparison matrices for better readability. 


C. PROCESS AREAS AT LEVEL 2 

1. Staffing 

With the size and complexity of today’s software, the number of people 
involved in the typical project has grown. These people need to be recruited, 
organized and allocated to specific tasks to provide the human resources 
required for development. The QMM questionnaire addresses the activities 
concerning staffing of the project. All goals of the process area staffing of the P- 
CMM are covered. 

2. Communication and Coordination 

The QMM highlights the importance of internal and external 
communication within a software development project. Questions concerning 
communication practices are even allocated a specific part within the 
questionnaire, and communication aspects are covered in detail. All goals of the 
process area staffing of the P-CMM are covered. 

3. Work Environment 

Provision of proper physical environment and resources is mainly seen as 
a responsibility of the organization. In contrast, the QMM contains questions 
about adequate attention and responses of the project management to problems 
in this process area. Possible resulting risks from deficiencies in the physical 
environment or resources are also covered in the risk management part of the 
QMM. The process area work environment is not a main focus of the QMM, but 
the process goals are covered. 

4. Performance Management 

Performance Management has two aspects - one looking at the people 
whose performance is managed, the other looking at the estimation and planning 
issues. The P-CMM as a self-contained model addresses both aspects in this 
process area, while the QMM addresses estimation and planning in the 
respective part of the questionnaire. In the combination of the questions from 
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different sections the QMM addresses all goals of the process area performance 
management. 

5. Training and Development 

The QMM treats training as an activity that needs to be carefully planned. 
Education and planning of training are seen as tasks of project management. 
The QMM addresses the relevant goals of the process area training. 

D. PROCESS AREAS AT LEVEL 3 

1. Competency Analysis 

At the unit level, competency analysis is related to planning and 
scheduling activities. Lack of capabilities may also pose risks that need to be 
managed. The QMM consequently focus on the effects of availability or lack of 
availability on a project. It addresses some aspects of competency analysis in the 
risk management and estimation/planning part. The evaluation of a formal 
establishment of work processes is underlying numerous questions that ask 
whether activities are formalized or are conducted regularly. In the combination 
of the questions from different sections the QMM addresses all goals of the 
process area competency analysis that are relevant for the unit level. 

2. Workforce Planning 

At the unit, level workforce planning is interwoven with project 
planning, and activities are performed to satisfy project-competency needs. In the 
combination of sets of questions from the estimation/planning and the people 
management area, the QMM covers the relevant goals of the process area 
workforce planning. 

3. Career Development 

The program manager will contribute to career development 
activities on the organizational level by providing performance information. On 
the unit level, the program manager has to be active in career development 
practices that require direct interaction with and knowledge of the individual in 
question. These activities are directly evaluated via the QMM questionnaire. The 
process goal of the process area dareer development that is relevant for project 
management is covered. 
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4. Participatory Culture 

During the development of the QMM, emphasis of the survey instrument 
was placed on culture and leadership aspects [Machniak 99], The QMM can be 
used to explore behavioral aspects of leadership affecting the micro-work 
environment beyond the more formal view of the P-CMM. All goals of the process 
area staffing of the P-CMM are covered. 

E. PROCESS AREAS AT LEVEL 4 

1. Empowered Workgroups 

A project team with the project manager granted responsibility and 
authority constitutes an empowered workgroup. Partitioning of the project team in 
further empowered workgroups depends on the size and complexity of the 
project, which is represented in the project’s work breakdown structure. Aspects 
regarding delegation of responsibility and partitioning of work are addressed in 
the QMM. The relevant goals of the process area Empowered Workgroups are 
covered in the QMM. 

2. Quantitative Performance Management 

Quantitative performance management is a core task for a project 
manager. Performance objectives are the necessary base for realistic planning 
and scheduling of work. Corrective actions are a key management activity when 
the performance achieved differs from the objectives. The QMM contains 
questions addressing quantitative performance management in its people 
management section, but establishes further on in its questionnaire a specific 
section (Estimation/Planning Management) to explore estimation, planning and 
scheduling aspects of project management in detail. The goals of the process 
area quantitative performance management are covered in the QMM. 

F. PROCESS AREAS AT LEVEL 5 

1. Continuous Capability Improvement 

Project managers should aspire to improve project team capabilities and 
processes even if the project is on schedule without cost overruns or other 
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problems. The ability to recognize improvement opportunities requires technical 
knowledge, interest in further professional and technical education, and 
participation in problem solving. The QMM addresses these factors. It evaluates 
whether the project manager has the necessary background to be aware of 
technical options, whether he is aware of the organizational and program status, 
possible problems and whether he listens to ideas and proposals. The goal of 
continuously improving the capability of operating and competency-based 
processes is not directly addressed by the QMM questionnaire. The questions 
contained in the QMM however ask for behavior, activities and necessary 
knowledge that provide a base for implementing improvements. 

Note that at the project management level, possible benefits of changes 
have to be compared to the impacts and risks generated from changing 
operating or competency-based processes in a running program. A program 
manager might be aware of possible improvements but decide not to implement 
them based on risk-management considerations. Even if the P-CMM raises goals 
concerning continuous capability improvement, it must be accepted that at the 
unit level, project necessities may hinder continuous implementation. The QMM 
questionnaire accommodates this situation. It does not penalize the program 
manager if he does not implement continuous improvement. It evaluates instead 
whether the necessary base for improvements is laid that enables the project 
manager to implement improvements if the project situation allows. 

Implementation of a question addressing improvement efforts (within given 
project constraints) might increase direct coverage of the process area goals. 
However, with regard of the different focus of QMM and P-CMM, this thesis sees 
the implementation of this process area in the QMM as being acceptable. 

2. Organizational Performance Alignment 

Performance alignment on the unit level is connected to task assignment, 

(i.e., planning activities like establishing a work breakdown structure), to problem 

solving in case of insufficient performance, and to leadership aspects such as 

reinforcement for performance. These activities are covered by the questions of 

the QMM. Institutionalization of these activities is further on covered implicitly by 
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the questions of the estimation/planning management part of the QMM. The 
goals of the process area Organizational Performance Alignment with relevancy 
on the unit level are covered in the QMM. 

3. Continuous Workforce Innovation 

The situation in the process area continuous workforce innovation is 
similar to the situation in the process area continuous capability improvement. 
Project managers should aspire to improve workforce practices and technologies 
even if the project is on schedule without cost overruns or other problems. The 
ability to recognize improvement opportunities requires technical knowledge, 
interest in further professional and technical education, and participation in 
problem solving. The QMM addresses these factors. It evaluates whether the 
project manager has the necessary background to be aware of technical options, 
whether he is aware of the organizational and program status, possible problems 
and whether he listens to ideas and proposals. The goals of identifying, 
evaluating and deploying innovative or improved practices and technologies are 
not directly addressed by the QMM questionnaire. The questions contained in the 
QMM however probe the behavior, activities and necessary knowledge that 
provide a base for implementing innovative or improved practices and 
technologies. 

Similar to the process area continuous capability improvement, note that 
at the project management level possible benefits of changes have to be 
compared to the impacts and risks generated from implementing innovative or 
improved practices and technologies in a running program. A program manager 
might be aware of possible improvements but decide not to implement them 
based on risk management considerations. Even if the P-CMM raises goals 
concerning continuous workforce innovation, it must be accepted that at the unit 
level project necessities may hinder implementations. The QMM questionnaire 
accommodates this situation. It does not penalize the program manager if he 
does not implement improvement or innovations. It evaluates instead whether the 
necessary base for recognition of innovations is laid that enables the project 
manager to implement innovations if the project situation allows. 
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Implementation of a question addressing innovation efforts (within given 
project constraints) however might increase direct coverage of the process area 
goals. However, with regard of the different focus of QMM and P-CMM, this 
thesis sees the implementation of this process area in the QMM as being 
acceptable. 
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V. FINDINGS AND RECOMMENDATIONS 


A. FINDINGS 

1. COMPLIANCE OF QMM WITH P-CMM 

The People Capability Maturity Model and the Quality Management Metric 
have different objectives. The P-CMM addresses the problems of managing an 
organization’s workforce. It categorizes five levels of maturity with associated 
capabilities and suggests specific processes and practices to achieve these 
capabilities. Processes and practices are addressed on the individual, unit and 
organizational level. It does not provide a ranking of processes and does not 
provide indications about possible implications of processes on success of 
software development projects. 

In contrast, the QMM measures the quality of software development 
management with regard to its impact on project success. It does not evaluate 
the capability of the organization; instead it focuses on the situation in a specific 
project. The QMM can be used to compare characteristics, practices, and 
specific behavioral aspects of the project manager against a set of ideal 
characteristics, best practices and positive leadership behavior. These elements 
are ranked in accordance with their respective impact on project success. The 
number of questions addressing a specific process and their level of detail 
depends on the importance of this process for the project success. A process 
with higher importance will be evaluated in a more detailed way than a supportive 
process. The QMM does not, however, question every implementation detail and 
allows projects to choose different implementations as long as the underlying 
goals are pursued. 

Due to their different objectives, QMM and P-CMM are not fully congruent 
with one another. The P-CMM addresses processes on the organizational level 
that are not the responsibility of project management and therefore are not 
addressed by the QMM. The P-CMM also maintains a uniform level of detail in 
describing processes while the level of detail in the QMM depends on the 
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contribution of the respective element to the project success. The QMM then also 
covers elements the P-CMM does not as they do not represent processes. 
Behavioral aspects and also some procedural aspects of the leadership style of 
the project manager are evaluated by the QMM as these aspects definitely have 
an impact on motivation of personnel and on the micro-work environment in the 
program, and hence, on project success. Finally there are some differences in 
wording that are attributed to the different orientation and purpose of P-CMM and 
QMM. 

Except for these objective - and purpose - related differences the QMM is 
in conformance with the P-CMM. The QMM questionnaire covers all processes of 
the P-CMM with relevancy for project management. The scoring of the QMM 
further on honors if project-established processes are conformant to processes 
described by the P-CMM. The QMM adds some additional questions regarding 
behavioral and procedural aspects on the implementation level that are beyond 
the scope of the P-CMM. Questions and scoring of the QMM however are in no 
case contradictory to the P-CMM, as the QMM in many respects subsumes the 
P-CMM. Overall the QMM represents a metric tool that evaluates the quality of 
people management on the project level in conformance with the P-CMM. 

2. RELATION OF QMM QUESTIONS TO P-CMM 

The QMM is not derived from the P-CMM. It is developed to measure the 
quality of management in a software development project with regard of its 
impact on the probability of success of the software development effort. Wording, 
detail level and organization of the questionnaire consequently differ from 
wording, detail level and organization of processes in the P-CMM. 

The questionnaire contains some questions addressing behavioral and 

procedural aspects on the implementation level that are beyond the scope of the 

P-CMM (see Table 17). Most of the questions, however, are correlated to 

processes that are contained in the P-CMM (see Appendix B). It is therefore 

possible for all P-CMM processes relevant for project management to identify 

related questions in the QMM. With regard of the intention of the QMM, it is also 

possible and even more important for all questions (except questions addressing 
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behavioral and procedural aspects) to identify processes that are related to a 
given question. 

If the results of a QMM survey indicate a low probability of success for a 
specific software development project due to management deficiencies, the 
relation of questions to processes will allow the identification of deficient 
processes and subsequent systematic improvement efforts. 

3. QMM AS QUANTITATIVE PERFORMANCE MEASUREMENT 
TOOL 

The purpose of quantitative performance management is to predict and 
manage the capability of competency-based processes to achieve measurable 
performance objectives. Performance characteristics are identified, measured 
and analyzed to allow performance management. 

Project management by itself is a competency-based process that 
contributes to the performance of unit objectives, that is, to the performance and 
success of a software development project. The performance objective of project 
management is to achieve successful software development. The underlying 
management processes determine the performance characteristics of project 
management. 

Previous work by Machniak [Machniak 99] and Grossman [Grossman 00] 
established and validated the QMM as a methodology to quantify the quality of 
project management and to predict success of the managed software 
development project. The QMM score therefore can be used as a measurable 
performance objective. This thesis shows that the QMM is in compliance with the 
P-CMM and its processes, that is, that measurable performance characteristics 
form the base of the QMM questions. The relation of QMM questions to P-CMM 
processes allows specific identification of deficient processes in case of 
deficiencies. 

In consequence the QMM can be used as a quantitative performance 
measurement tool as described on the predictable level of the P-CMM. The QMM 
allows one to measure performance characteristics of project management, and 
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to both predict and manage performance objectives (i.e., success probability). 
Based on the correlation of QMM questions and P-CMM processes, users can 
take corrective actions when the predicted performance deviates from objectives. 
B. RECOMMENDATIONS FOR FUTURE WORK 

The recommendations for future work include updating and further testing 
of the QMM survey instrument, analyzing and assessing the effects of using 
QMM as a measurement tool in quantitative performance management, and 
integrating the QMM survey instrument results into existing cost, schedule and 
risk models to improve program estimation accuracy. 

Updating the QMM survey instrument includes updating the focus of the 
survey instrument, updating the organization of questions, refining the wording of 
questions, and refining the weighting of questions. Software development 
management methods are changing on a continuous basis. The QMM survey 
instrument needs to be updated to reflect these changes and to ensure that its 
focus is on the management aspects relevant for the success of software 
development. Changes in methods and technologies might also cause 
replacement of questions or changes in the weighting of questions. 

The QMM partitions questions into the four management areas: people 
management, estimation/planning management, risk management, and 
requirements management. As maturity models such as the P-CMM become 
widely used, the allocation of questions should be revised for a better alignment 
of the survey instrument with the corresponding models. 

The QMM survey instrument requires ongoing validation. The QMM 
should also be applied to software development projects of different size to 
determine possible needs for adjustments of the weighting factors based on 
project size. 

The correlation of QMM elements to process goals of the P-CMM allows 
determining people management processes that need implementation or 
improvement based on the QMM results. In combination with the aforementioned 
validation activities, one could assess the effects of using the QMM as a 
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measurement tool in quantitative performance management as a basis for 
adjusting measures of correlation between QMM and P-CMM. 

This thesis focused on the people management part of the QMM as its 
highest weighted part. The correlation between QMM and P-CMM provides a 
feedback to the program manager, helping him to identify processes that need 
implementation or improvement. Further research is required to evaluate the 
questions of the other QMM management areas and to relate them to other 
models where applicable. 

Previous QMM surveys have been executed using a paper form of the 
questionnaire. An introduction had to be given to the survey attendants as the 
questions are formulated quite tersely for practical reasons. The development of 
an automated, preferably web-based QMM survey tool would generate a number 
of benefits. Integrated help functions and information texts would reduce the 
need for an introduction. The survey could be conducted when convenient for the 
project manager without the need for a researcher or examiner to be present. 
Scoring of questions and relations between answers and success probabilities or 
improvement suggestions could be concealed to prevent biased answers. Data 
from different surveys could be used to indicate trends, and data from different 
projects could be more easily analyzed and compared. 

One could also investigate how the QMM results should be used as input 
to estimation models to improve the accuracy of estimations. Currently these 
models do not consider the quality of software-development management. If the 
performance of software-development management is managed quantitatively, at 
best all possible deficiencies are eliminated. Thus, even an initially deficient 
management might be able to improve its performance and finally perform as a 
good management. In this case, no adjusting inputs to current estimation models 
are necessary. In all other cases an input factor to estimation models based on 
the quality of management would increase the accuracy of estimations. 
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Figure 5. Requirements Management Pair Choice Questions Page 1 (from: 

Machniak 99]) 
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Program Name_ Page 2 of 8 Date 







































Figure 7. Estimation/Planning Management Pair Choice Questions Page 1 (from: 

Machniak 99]) 
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Estiinalion/Planning Management page 1 of 2 score 







Figure 8. Estimation/Planning Management Pair Choice Questions Page 2 (from: 

Machniak 99]) 
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Pair choice section THREE; (People Management) choose most applicable term of the two for each row (page 1 of 2): 
Human Resources 



Figure 9. 


People Management Pair Choice Questions Page 1 (from: Machniak 99]) 
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Figure 10. People Management Pair Choice Questions Page 2 (from: Machniak 99]) 


60 




© © ® <=> <=> 


© © © © © © © © 


'Sfi § 

a s 3 

5 a 2 

— u P. 

■8 2 s 


Ss-s 

* g i 

3 Ot > 

■ a a 2 

■ O C JS 


’ u » ■£ 

; 5 2 v. 

\ &.S £ 

I G -D O 

rg s a 

i o £ 8 

; O Ph 


s? 

•S a 0 . 
Jo ! o 

2 wj ; rt 1 
on! ^3 

^ Jdj L 

o .2 o 

£ hz;; 


c c u 

o C/3 

?1'8 S 

i is <3 .* 

« S -2 

a 3 13 

'Cog 
■ T3 o C 

.3 & <3 ■ 
o o o 
£ £ £ : 


MHo © © © © © 


I <^IO Oh-H © O © «-< 


- - - - ~ - - ~ <=> 


E C 

3 -a -S "O 
‘ .5 t> £ 
o c jS 
a r p *3 

^ "c "P 
.52 § g 


§ 1 -3 

5 E I 


M ^ M\ 

.on in 

2 2 21 


o p 

O O 

I 1 

,~j rrt C3 

* JJ g 

M 03 '‘- 1 

is 
! |l| 
!lal 


s «? 
u s 

8 “J 

s 

' c o 

^ <Q 

£ V •“ 
^ « 2 
S a S 
■8 « 13 
? -S B 
j 2 

U n tfl 

j< g 
ra J5 .S3 

CO U Si 


_ .1 a 


CJ 

M *4 o 

2 .22 P 

_ t/i 

o o 

C3 C3 ■ — 

w w Pi 


,£J *TU 

SbI 
£.2 S 

I 

^ S o 
.2 s g 

£ « 3 

u .2 « 

g *—• Vh 
cn O r 

III 

cn O cO 
CJ O 2 


Figure 11. Risk Management Pair Choice Questions Page 1 (from: Machniak 99]) 
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Figure 12. Risk Management Pair Choice Questions Page 2 (from: Machniak 99]) 
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Program Name _ YES-NO-N/A Questionnaire Scoring Template Date 


No. Requirements Management Questionnaire_ Yes No N/A 


m 

PM chose to have a formal requirements list 

El 

J_2_ 

El 


m 

Requirements recorded in some way 

IB 

El 

El 


m 

Written requirements were part of some formal document 

L_L 

O 

El 


m 

Written requirements were informal 

MM 

MM 

El 


m 

At least some requirements were oral only 

KM 

MM 

B 



All stakeholders were identified 

B 

El 

ra 


7 

Alt stakeholders participated in the requirements extraction 

B 

El 



8 

Some stakeholders participated in the requirements extraction 

MM 

El 

B 


m 

Management extracted requirements, no stakeholder involvement 

J_L 

MM 

B 



Management passed requirements to development team 

MM 

L°_ 

B 


ma 

Stakeholders not involved in Management extraction, but approves 

MM 

IB 

L° 


m 

Management gets inputs from stakeholders, Ihen develops requirments 

MM 

B 

ra 


me 

Developers work informally with users to arrive at requirements 

MM 

IB 

B 


me 

Same as 13, but management oversees and formalizes 

MM 

B 

B 


II 

If a waterfall or sequential development strategy: 




EE 

All requirements complete before design 

MM 

IEI 

B 


EE 

Some requirements left incomplete prior to design 

El 

ra 

B 


EH 

Requirements informal prior to design effort 

El 

B 

0 


me 

Requirements serve as input 


El 

B 


EE 

Lenqth of time for requirements work greater than development work 

MM 

El 

B 


EE 

Requirements developed in parallel to design 

El 

n 

ra 


OR 

If a prototype, throwaway, or other development strategy: 


HH 


EE 

Learn about requirements through development efforts 


El 

El 


HE 

No codinq until all requirements are defined 

El 

MM 

El 


EH 

Requirements formal prior to design effort 

El 

El 

0 


■(:’ 

Requirements serve as output 


El 

0 



Requirements definition work in parallel to development efforts 

MM 

El 

0 


HI 

Requirements developed in parallel to design 

i 

El 

0 


mi 

Are requirements frozen at some phase 

D 

El 

_L_ 


mi 

Change management exists 

El 

B1 

0 


wm 

Chanqe management is forma! 

El 

B 

0 


mi 

Project strategy is consistent throughout development 

El 

o 

El 


9® 

Requirements are updated 

MM 

El 

B 


EE 

Configuration Management (CM) exists 

El 

El 

0 


mk 

CM is formal 

El 

El 

El 


MR 

Requirements are testable 

MM 

El 

El 



Requirements testing considered/implemented during extraction 

MM 

B 

El 


nn 

Requirements testing plan exists 

MM 

El 

0 


ED 

Requirements testing is formal 

El 

El 

0 


ma 

All requirements have priorities 

MM 

El 

0 


EE 

All requirements must be implemented 

El 

MM 

0 


ED 

Requirements are tested 

a 

MM 

0 


■cH 

All requirements are equally important 

o 

MM 

0 



At least some requirements have priorities 

n 

B 

0 


eh 

All requirements are traceable 

n 

a 

0 


MR 

Traceability not important 

El 

1 

El 


MR 

Each requirement has an author 

U 

B! 

El 


EE! 

Who authored requirement is not important 

o 

El 

ra 


ED! 

Initial set of requirements to be implemented, no requirements creep 

o 

— 

ra 


ESI 

Structured and tracked changes to requirements only 

El 

El 



■HI 

Chanqe is inevitable, changes allowed at all times 

El 

n 

ra 


mb 

Chanqe is inevitable, but changes limited 

n 

El 

El 


■El 

Requirements control funding 

i i 

B 



KXDI 

Requirements history kept 

MM 

El 

Eli 


■HI 

Baseline established for requirements at some point prior to develop 

MM 

MM 

El! 


TOTAL SCORING] 

—J 



_i 


Fntor fntal sonra nn OMM srare sheet block e. 


Figure 13. Requirements Management YES/NO-N/A-Questions (from: Machniak 

99]) 
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Program Name _ YES-NO-N/A Questionnaire Scoring Template Date_ 


No. Estimation/Planning Questionnaire_Yes No N/A 


o 

A volume product metric used (LOC, # of files. # of screens, pages of doc) 

IEI 

MM 

ra 

m 

Measure used for various product elements (modules, components, CSCI) 

i 

MM 

ra 

m 

Product measures made by phase (amt at implementation, LOC changed at unit test) 

i 

o 

ra 

m 

Other product attributes measured (FP, throughput, mem cap, cydomatic complexity) 

i 

ra 

ra 

m 

Product metrics tracked and updated throughout program execution 

IB 

D 

ra 

ML 

Event count process metric used (# defects in test, reqmt changes, milestones met) 

i 

o 

m 

m 

Time measure process metric used (cycle time) 

i 

u 

ra 


Process metrics tracked and updated throughout program execution 

m 

D 

ra 

m 

Program cost estimations made from product or process metrics 

n 

D 

ra 

10 

Program cost estimations tracked and updated to reflect progress/changes 

i 

D 

ra 

ME 

Factor analysis performed on program 

i 

ra 

ra 

ME 

Program’s primary purpose, including major functions and deliverables known 

IB 

D 

ra 

ME 

Work breakdown structure developed 

IB 

O 

ra 

ME 

Task estimated with realistic expectations of productivity probabilities 

B 

MM 

ra 

MM 

Schedules developed based on realistic expectations 

nr 

B 

ra 

■E 

Schedules tracked and updated based on new information 

ID 

B 

ra 

ME 

Detailed activity lists used for clearly defined completed/not completed tasks 

ID 

B 

JU 

MM 

Quality assurance plan or similar to aid in detecting defects early in program 

Li 

B 

ra 

19 

COCOMO estimates performed 

n 

B 

ra 

B 

CSCI dearly defined and tasked 

IB 

B 

ra 

Kl 

Estimates completed ad hoc 

B 

c 

ra 

W?i 

Gantt charts used and updated 

i 

B 

ra 

E3 

Resource estimations (working hrs, job categories, task activities) done 

i 

B 

ra 

mu 

Earned value established 

MM 

B 

ra 

■sa 

Earned value tracked throughout program 

MM 

o 

on 

ME 

Quality expectations established for product with users and stakeholders 

i 

B 

ra 

Wfk 

Critical path for program tasks developed and tracked 

MM 

B 

ra 

|28 

Meaure of effectiveness (MOE) or Figure of merit established and tracked 

i 

D 

0 

«E2 

Estimates are updated routinely 


B 

ral 

30; 

Schedules are updated routinely 

MM 

B 

ol 

ra 

Estimations are made by program management (top-down) 

n 

ra 

mm 

MS 

Estimations are made by program team members (bottom-up) 

MM 

ra 

ra 

MM 

Automated program tracking used 


ra 

ra 

ME 

PM usually thorough in tracking and reporting schedules and financials 

D 

B 

ra 

MM 

WBS developed only as data call, not used in planning 

B 

ra 

ra 


Earned value used to track program progress 

MM 

MM 

ra 

m 

PM insists on prioritizing work reduction as schedule/funding compromised by stakeholders 

Dl 

D 

0 

38 

Estimations are done using both top down and bottoms up approaches 

MM 

B 

Ol 

39 

All program team members involved in planning process 

Bl 

B 

ral 

■E1H 

Hardware also considered in estimation process 

Dl 

B 

ral 

KB 

Program history compiled 

Dl 

ra 

Ol 

MS 

System upgrades (SCR) software changes requests estimated individually 

Dl 

B 

ral 

ME 

Management duties apart of each team member's responsibilities 

Dl 

U 


ME 

PM dictates schedules to program team 

Dl 

0 

ra| 

ME 

Code reviews planned in schedule 

in 

-i 

ra 


Defined tangible milestones established for program tasks 

B 

Bl 

ral 

ESI 

Test planning done at the start of the program 

n 

Bl 

0 

48 

Estimations are completed by those performing the tasks 

D 


0 

49 

Sensitivity analysis performed for program choices 

U 

Bl 

ral 

E2!]| 

Software deployment planning completed 

o 

Bl 

ral 

TOTAL SCORING] 


ITT 


Enter total score on QMM score sheet block f. 


Figure 14. Estimation/Planning Management YES/NO-N/A- Questions (from: 

Machniak 99]) 
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Program Name_ YES-NO-N/A Questionnaire Scoring Template Date 


No. People Management Questionnaire_ Yes No N/A 


nr 

PM is accessable in person by each team member 

iD 

IE1 

0 

m 

PM is accessable via email by each team member 

U 

IB 

0 

m 

PM is accessable via phone by each team member 

Ll_ 

1° 

0 

m 

PM not only considers a person's suitability, not also desire to be on a team 

n 

ra 

ra 

m 

PM consults with each team member regarding their career goals 


ra 

ra 

m 

PM regularly holds meetings to inform team of program progress 

IB 

B 

ra 

mk 

PM solicits opinions from team members before making decisions 

IB 

n 


n* 

PM lets teams make decisions affecting their work 

ID 

B 

ra 

m 

PM frequently makes decisions without any consultation with members 

iD 

B 

ra 


PM understands the technology/language of the program 

IB 

El 

ra 

ma 

PM is able to communicate with other the technical issues in the program 

D 

ra 

ra 

ms 

PM prioritizes problems or conflicts within the program 


B 

ra 

me 

PM assists team members in developing/advising of career path 

i 

El 

ra 

ra 

PM empowers program members to recommend hiring new team members 

ID 

El 

ra 

me 

PM empowers program members to recommend firings of other members 

D 

El 

ra 

ME 

PM specifically assigns work to each program member 

D 

ra 

ra 

■B 

PM sets communication protocol to be followed 

D 

ra 

ra 


PM allows unrestricted communications 

n 

ra 

ira 

mm 

PM readily makes tough decisions 

mu 

El 

ra 


PM takes control in difficult/ problem areas 

D 

o 

ra 

MZ1 

PM looks ahead to new proqrams, new upgrades of existing program 

D 

ra 

ra 


PM maintains regular communications with all stakeholders 

B 


ra 


PM maintains regular communications with users 

B 

El 

ra 

KS! 

PM encouraqes program team communication with users 

i 

El 

El 

wem 

PM encourages program team communication with stakeholders 

i 

El 

0 

F&l 

PM facilitates horizontal communication within program 

i 

El 

0 

ma 

PM facilitates communication during integration 

i 

El 

ra 


PM holds meetings without clear objectives listed prior to meeting 

D 

B 

ra 

29 

PM must approve all decisions within the program 


B 

° 

■ail 

PM must approve all interactions with stakeholders 

D 

ra 

ra 

ED 

PM must approve all interactions with users 

n 

mm 

ra 

EH 

PM makes all presentations to stakeholders/users 

El 

mm 

ra 

■etc] 

PM is considered ''flexible" in terms of program members personal issues 

i 

ra 

ra 

ESI 

PM, at least occasionally, schedules/promotes outside work team activities 

i 

ra 

El 

Hd 

PM is readily willing to listen to program problems and complaints 

D 

El 

0| 

E3 

PM takes action to resolve program problems and complaints 

D 

El 

ra 

EB 

PM is generally respected by stakeholders, users, and organization 

Bi 

El 

_2J 


PM sometimes fails to grasp important technical issues in program 

m 

_L 

ra 

gEi 

PM recruits proqram team members from outside organization 

MM 

El 

ra 

40 

PM directs what needs to be done and directs how to do it 

Ell 

a 

ra 

EB 

Proqram personnel have clearly defined specific tasks 

ra 

mm 

ra 

ms 

Although individual's tasks are specific, each exposed to the "bigger picture" 

BI 

El 

ra 

ESI 

PM has clearly defined his/her expectations for each individual 

BI 

Ell 

0 

ESI 

PM delegation of duties is usually seemless in execution 

Dl 

ra 

0 

ESI 

PM acts as facilitator to solving personnel conflicts 

BI 

Ell 

ra 

46 

PM attempts to motivate individuals on the program team 

BI 

Dl 

Ell 

ESI 

PM clearly separates technical from managerial roles for individuals 

0 

Dl 

0 

ESI 

PM directs how he/she expects the task to be accomplished 

Ell 

Dl 

0 

49 

PM directs what needs to be done, but does not direct how 

BI 

El 

ra 


PM attempts to spotlight individuals in the program for positive exposure 

BI 

Ell 

Eli 

TOTAL SCORING! 





Enter total score on QMM score sheet block g. 


Figure 15. People Management YES/NO-N/A- Questions (from: Machniak 99]) 
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Program Name _ YES-NO-N/A Questionnaire Scoring Template Date. 


No. Risk Management Questionnaire 

jf 

</> 

No 

N/A 


Risk Management (RM) is specifically an activity in the program 

m 

IE1 

ira 

2 

RM is formal and documented 

El 

IE1 

ira 

m 

A specific RM plan exists 


IB 

ira 

4 

RM is required in the program, but not used during the program 

nr 

rr 

ra 

m 

RM is done prior to the program execution 

MM 

IE1 

ira 

6 

RM is done by an outside entity to the development 

i 

0 

0 

7 

RM is done internally only 

0 

i 

0 

8 

RM is both internally performed and externally assessed 

i 

ID 

ira 

m 

RM planning occurs during or after major milestones in the program 

i 

ID 

ira 

Kl 

Risk Assessment is only a management function 

O 

ID 

ira 

ML 

RM is informal or non existent 

D 

ID 

0 

ME 

There is a RM plan, but it is not updated or tracked 

n 

ID 

0 

ME 

Risks are only generalized 

El 

IEI 

ira 

ML 

Each risk is delineated 

MM 

ira 

ira 

ME 

Each risk has a consequence 

mu 

ira 

iol 

16 

Each risk has a likelihood rating of some sort 

i 

0 

0 

ME 

Each risk has a mitigation strategy 

i 

0 

0 

18 

Risk Management is automated 

i 

El 

ra 

BE 

Risks are tracked 

MM 

MM 

ra 

El 

Regret analysis performed 

MM 

D 

ra 

Bjj 

RM drives decisions in the program 

mm 

MM 

ra 

E3 

Risks have probabilities 

i 

0 

ra 

m 

Risk Management is ad hoc 

El 

0 

0 

m 

RM information is shared with all stakeholders (as appropriate) 

n 

0 

0 

26 

Risks are weighed relative to other program risks 

MM 

ra 

ra 


Risk Assessment is a program team activity 


0 

0 

28 

Risk Assessment done prior to program start 

MM 

-1 

0 

29 

Risk Assessment includes personnel risk 

i 

ra 

ra 

Bt!i1 

RM uses tools, but depends on human decisions 

MM 

ra 

ra 

ED 

Risk Assessment includes cost risks 

i 

El 

rai 

S2 

Risk Assessment includes schedule risks 

MM 

0 

0 

ES 

Risk Assessment includes technology risks 

i 

ra 

Ell 


Risk Assessment is briefed organization structure above program manager 

i 

ra 

0 

El 

Risk Assessment includes requirements risks 

H 

ra 

0 

36 

Risk Assessment includes user risks (too little involvement of user) 

MM 

El 

0 

EB 

Risk Assessment includes documentation risks 

MM 

o 

0 

EJ 

Risk Assessment includes integration risks 

MM 

ra 

0 

39 

Risk Assessment includes interface risks (non-standard) 

MM 

El 

Ell 

ed 

Risk Assessment includes continuing requirements change (feature creep) 

a 

ra 

0 

EO 

Risk Assessment includes dependent projects/programs risks 

u 

El 

0 

ea 

Documentation proof exists to demonstrate following risk management plan 

MM 

ra 

Ell 

EE) 

High risk have measured tracking (high profile status) 

i 

0 

0 

44 

Organizational history used to search for risks 

i 

0 

0 

LB 

Other organizational checklists used for risk assessment 

MM 

El: 

0 

ED 

Internal organizational checklists used for risk assessment 

i 1 

0 

0 

EB 

Risk Assessment information contributed to internal or other database 

MM 

ra 

0 

ED 

Risk Assessment includes internal organization risks 

MM 

ra 

0 

ED 

Risk Assessment includes stakeholder risks 

MM 

ra 

rai 

K*1 

No risk management needed; program is straightforwarded & understood 

El 

MM 

ol 

TOTAL SCORING] 





Enter total score on QMM score sheet block h. 


Figure 16. Risk Management YES/NO-N/A- Questions (from: Machniak 99]) 
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APPENDIX B - BLANK COMPARISON MATRIX 


No. 

Questions of the Quality Management Metric 

Process Area Goal Evaluated 


Questions of People Management Part 






P001 

Long range organizational vision / 

Short term program and immediate work focus 






P002 

Lead through personal attention to others / Action-oriented leadership 
approach 






P003 

Run as much of the organization as possible / let team make decisions as 
much as possible 






P004 

Direct and domineering style / 

Encourage independence of others 






P005 

Traditional leaders respect hierarchy / Do what needs to be done 






P006 

Win cooperation rather than demand it / 

Tough-minded with others 






P007 

Act strongly and forcefully in the field of ideas / Prefer to lead other 
independent types while seeking autonomy for self 






P008 

Consults with team members to find solutions to problems / Consults team 
members to get validation of program manager’s (PM) predetermined 
solution 






P009 

Keep people well informed / Only as much knowledge as necessary for 
their work 






P010 

Make things happen by focusing on the immediate problem / Long range 
focus and de-emphasize current problem 






P011 

Manage others loosely and prefer minimal supervision / Follow traditional 
procedures and rules conscientiously 






P012 

Leadership, management decisions exclusively by PM / PM makes 
decisions but gets inputs from team 






P013 

Team-program manager relationship adult-adult / Team-PM relationship 
parent-child 






P014 

PM makes decisions but gets inputs from team / All program team 
members responsible for program decisions 






P015 

When a problem arises: management takes over to solve it / Management 
lets the team solve the problems 






P016 

Leadership is do as 1 say, not do as 1 do / Leadership by example 






P017 

Program expectation not influenced by PM / Program expectation 
managed by PM 






P018 

PM gives freedom to team, but does has no mentoring for leaders / PM 
empowers teams by mentoring members to be leaders 






P019 

PM waits and sees what happens then plans / Management plans far in 
advance 






P020 

PM is reacts to emergencies / Management is one step ahead of problems 






P021 

Facilitative approach to solving problems / Take charge readily and often 






P022 

PM is complex, takes much time to understand / Management is simple, 
easy to figure out 






P023 

PM prefers to plunge right in / Takes time to separate things to be done 
and order of doing them 






P024 

PM reacts to needs of the moment / Methodically follows plans 






P025 

PM has technical experience particular to the particular s/w program / PM 
relies on team members solely 






P026 

PM participates in technical reviews / PM only in non-technical reviews 






P027 

PM participates in making technical decisions when problems arise / PM 
delegates technical questions 






P028 

PM does not get involved discussing technical options / PM contributes to 
technical options when discussed 






P029 

PM does not review technical options and decisions / PM reviews technical 
options and decisions 
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No. 

Questions of the Quality Management Metric 

Process Area Goal Evaluated 

P030 

PM actively attempts to keep up-to-date with current technology and 
standards / PM is removed from cutting edge technology issues 






P031 

PM receives technical periodicals and occasionally references applicable 
articles / PM doesn’t read periodicals nor references current articles to 
team 






P032 

PM doesn’t have technical background (or education) / PM has technical 
background (or education) 






P033 

Team members avoid PM when they need technical advice / Team 
members generally consider talking to PM regarding technical issues 






P034 

Program members have clearly defined, segmented roles / Work 
responsibilities are shared 






P035 

Formal team building procedures are used / No formal team building is 
emphasized 






P036 

Program manager flexible regarding work hours / Program manager 
maintains strict standards for work hours 






P037 

Big picture conveyed to all team members by PM / PM focuses on the 
partitioned tasks with team 






P038 

People issues dealt with primarily through indirect methods (email, memo 
etc) / People issues dealt with primarily through direct methods (face-to- 
face) 






P039 

Training is required and planned on a regular basis / Training is ad hoc 






P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 






P041 

Consideration for team members’ career goals are reflected in 
assignments / Team members must adapt to tasks that are assigned 






P042 

Team members assignments and responsibilities are mostly dictated by 

PM / Assignments and responsibilities are discussed and agreed upon with 
PM 






P043 

Management leads in problem solving / Management facilitates and lets 
team lead in problem solving 






P044 

Management welcomes problems as challenges and opportunities / 
Management views problems as obstacles and grounds for punishment 






P045 

Team members participate in performance evaluations of peers / 

Personnel evaluations are strictly PM responsibility 






P046 

Management reinforcement feedback sparse and inconsistent, if any / 
Management provides timely reinforcement feedback for positive 
behaviors 






P047 

Management provides basic needs of office facilities fairly well / Office 
facilities are a drawback to working in the program 






P048 

Working conditions are fairly comfortable, time off policy “flexible” / 

Working conditions and time off policy is inconsistent and difficult at times 







People Management Part - YES-NO-N/A Questions 






P049 

Communications primarily written (email, memo, etc.) / Communications 
primarily verbal (face-to-face) 






P050 

Detailed instructions: oral presentation, follow-up email, memo, etc. / 

Email, memo, etc. only 






P051 

Formal communication protocol / Informal communications 






P052 

External vertical communications restricted / External vertical 
communication allowed 






P053 

Coders notebook, weekly accomplishment reports required / Not required 






P054 

User-coder relationship established, encouraged, and mediated / User- 
coder interaction minimized 






P055 

Meetings structured to minimize wasted time / Meetings unstructured and 
open ended 






P056 

Meetings have agenda, objectives, and conclude with action items / 

Meeting agenda fluid and open ended 






P057 

PM and coder communication face to face / PM and coder communication 
primarily email 






P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 







68 




No. 

Questions of the Quality Management Metric 

Process Area Goal Evaluated 

P059 

Open communications is encouraged / Communication through chain of 
command only is encouraged 






P060 

Program manager is accessible for discussions / Program manager difficult 
to get an appointment to see 






P061 

PM (PM) is viewed as separate from team / PM mixes with team frequently 






P062 

Management regularly holds team meetings / Meetings are sporadic 






P063 

Meetings are structured with definite goals and objectives / Meetings are 
informal 






P064 

PM is generally easy to reach and talk to / PM is usually hard to get a hold 
of and difficult to talk to 






P065 

Team-PM relationship adult-adult / Team-PM relationship parent-child 






P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 






P067 

Work is seen as complex processes involving team working together / 

Work broken into pieces with minimal team member interaction 






P068 

Action items sometimes are not followed through / Action items 
communicated and followed thoroughly 






P069 

Team members require frequent clarifications by PM for assigned tasks / 
Team members rarely require clarifications by PM for assigned tasks 






P070 

PM is accessible in person by each team member 






P071 

PM is accessible via email (memo, letter) by each team member 






P072 

PM is accessible via phone by each team member 






P073 

PM not only considers a person's suitability, not also desire to be on the 
team 






P074 

PM consults with each team member regarding their career goals 






P075 

PM regularly holds meetings to inform team of program progress 






P076 

PM solicits opinions from team members before making decisions 






P077 

PM lets teams make decisions affecting their work 






P078 

PM frequently makes decisions without any consultation with members 






P079 

PM understands the technology/language of the program 






P080 

PM is able to communicate with others the technical issues of the program 






P081 

PM prioritizes problems or conflicts within the program 






P082 

PM assists team members in developing / advising of career path 






P083 

PM empowers program members to recommend hiring new team 
members 






P084 

PM empowers program members to recommend firings of other members 






P085 

PM specifically assigns work to each program member 






P086 

PM sets communication protocol to be followed 






P087 

PM allows unrestricted communications 






P088 

PM readily makes tough decisions 






P089 

PM takes control in difficult /problem areas 






P090 

PM looks ahead to new programs, new upgrades of existing program 






P091 

PM maintains regular communications with all stakeholders 






P092 

PM maintains regular communications with users 






P093 

PM encourages program team communication with users 






P094 

PM encourages program team communication with stakeholders 






P095 

PM facilitates horizontal communication within program 






P096 

PM facilitates communication during integration 






P097 

PM holds meetings without clear objectives listed prior to meeting 






P098 

PM must approve all decisions within the program 






P099 

PM must approve all interactions with stakeholders 






P100 

PM must approve all interactions with users 






P101 

PM makes all presentations to stakeholders / users 






PI 02 

PM is considered “flexible” in terms of program members personal issues 






P103 

PM, at least occasionally, schedules/promotes outside work team activities 
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No. 

Questions of the Quality Management Metric 

Process Area Goal Evaluated 

PI 04 

PM is readily willing to listen to program problems and complaints 






P105 

PM takes action to resolve program problems and complaints 






P106 

PM is generally respected by stakeholders, users, and organization 






P107 

PM sometimes fails to grasp important technical issues in program 






P108 

PM recruits program team members from outside organization 






P109 

PM directs what needs to be done and directs how to do it 






P110 

Program personnel have clearly defined specific tasks 






Pill 

Although individual’s tasks are specific, each exposed to the “bigger 
picture” 






P112 

PM has clearly defined his/her expectations for each individual 






P113 

PM delegation of duties is usually seamless in execution 






P114 

PM acts as facilitator to solving personnel conflicts 






P115 

PM attempts to motivate individuals on the program team 






P116 

PM clearly separates technical from managerial roles for individuals 






P117 

PM directs how he/she expects the task to be accomplished 






P118 

PM directs what needs to be done, but does not direct how 






P119 

PM attempts to spotlight individuals in the program for positive exposure 







Relevant Questions from the Risk Management Part 






R001 

Risk Assessment includes personnel risk 






R002 

Internal organizational checklists used for risk assessment 






R003 

Personnel risks examined / No personnel risks examined 






R004 

Risk management plan updated regularly 






R005 

Risk Management is formal and documented / Risk Management is 
informal, if at all 






R006 

Resource risks examined / No resource risks examined 







Relevant Questions from the Estimation/Planning Management Part 






E001 

Work breakdown structure developed 






E002 

Task estimated with realistic expectations of productivity probabilities 






E003 

Develop work breakdown structure / Assign work as needs arise 






E004 

Resource evaluations made for program / No resource evaluations for 
planning 






E005 

Estimates updated at reviews / Estimates constantly updates (in between 
reviews, too) 






E006 

Work breakdown structure has objective measure of completeness 






E007 

Training part of estimates/Training omitted in estimates 






E008 

Team possibilities considered for planning of program / no consideration 
for outside teaming possibilities 







Table 1. Blank Comparison Matrix 
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APPENDIX C - EVALUATED COMPARISON MATRICES 


A. LEVEL 2: MANAGED 

1. Process Area Staffing 

• Goal 2.a.1: Individuals or workgroups in each unit are involved in 
making commitments that balance the unit’s workload with 
approved staffing. 

• Goal 2.a.2: Candidates are recruited for open positions 

• Goal 2.a.3: Staffing decisions and work assignments are based on 
an assessment of work qualifications and other valid criteria 

• Goal 2.a.4: Individuals are transitioned into and out of positions in 
an orderly way. 

• Goal 2.a.5: Staffing practices are institutionalized to ensure they 
are performed as managed processes. 




2.a.1 

2.a.2 

2.a.3 

2. a. 4 

2.a.5 

P008 

Consults with team members to find solutions to problems / Consults team 
members to get validation of program manager’s (PM) predetermined 
solution 

X 





P012 

Leadership, management decisions exclusively by PM / PM makes 
decisions but gets inputs from team 

X 





POM 

PM makes decisions but gets inputs from team / All program team 
members responsible for program decisions 

X 





P019 

PM waits and sees what happens then plans / Management plans far in 
advance 

X 





P020 

PM is reacts to emergencies / Management is one step ahead of problems 




X 


P024 

PM reacts to needs of the moment / Methodically follows plans 




X 

X 

P034 

Program members have clearly defined, segmented roles / 

Work responsibilities are shared 




X 


P035 

Formal team building procedures are used / 

No formal team building is emphasized 


X 

X 



P042 

Team members assignments and responsibilities are mostly dictated by 

PM / Assignments and responsibilities are discussed and agreed upon with 
PM 

X 





P050 

Detailed instructions: oral presentation, follow-up email, memo, etc. / 

Email, memo, etc. only 




X 


P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 

X 





P077 

PM lets teams make decisions affecting their work 

X 





P083 

PM empowers program members to recommend hiring new team 
members 


X 




P084 

PM empowers program members to recommend firings of other members 


X 


X 


P108 

PM recruits program team members from outside organization 

X 

X 

X 



Pill 

Although individual’s tasks are specific, each exposed to the “bigger 
picture” 

X 





P112 

PM has clearly defined his/her expectations for each individual 



X 



P118 

PM directs what needs to be done, but does not direct how 

X 





R001 

Risk Assessment includes personnel risk 





X 

R002 

Internal organizational checklists used for risk assessment 





X 


71 






2.a.1 

2.a.2 

2.a.3 

2. a, 4 

2.a.5 

R003 

Personnel risks examined / No personnel risks examined 





X 

R004 

Risk management plan updated regularly 





X 

R005 

Risk Management is formal and documented / Risk Management is 
informal, if at all 





X 

E001 

Work breakdown structure developed 



X 



E002 

Task estimated with realistic expectations of productivity probabilities 



X 




Table 2. Process Area Staffing 


2. Process Area Communication and Coordination 

• Goal 2.b.1: Information is shared across the organization 

• Goal 2.b.2: Individuals or groups are able to raise concerns and 
have them addressed by management 

• Goal 2.b.3: Individuals and workgroups coordinate their activities to 
accomplish committed work 

• Goal 2.b.4: Communication and Coordination practices are 
institutionalized to ensure they are performed as managed 
processes 




2.b.1 

2.b.2 

2.b.3 

2.b.4 

P001 

Long range organizational vision / 

Short term program and immediate work focus 

X 




P009 

Keep people well informed / Only as much knowledge as necessary for 
their work 

X 




P037 

Big picture conveyed to all team members by PM / PM focuses on the 
partitioned tasks with team 

X 




P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 

X 




P049 

Communications primarily written (email, memo, etc.) / Communications 
primarily verbal (face-to-face) 



X 


P051 

Formal communication protocol / Informal communications 




X 

P055 

Meetings structured to minimize wasted time / Meetings unstructured and 
open ended 



X 


P056 

Meetings have agenda, objectives, and conclude with action items / 

Meeting agenda fluid and open ended 



X 


P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 

X 




P060 

Program manager is accessible for discussions / Program manager difficult 
to get an appointment to see 


X 



P061 

PM (PM) is viewed as separate from team / PM mixes with team frequently 


X 



P062 

Management regularly holds team meetings / Meetings are sporadic 

X 

X 



P063 

Meetings are structured with definite goals and objectives / Meetings are 
informal 



X 


P064 

PM is generally easy to reach and talk to / PM is usually hard to get a hold 
of and difficult to talk to 



X 


P070 

PM is accessible in person by each team member 



X 


P071 

PM is accessible via email (memo, letter) by each team member 



X 


P072 

PM is accessible via phone by each team member 



X 


P075 

PM regularly holds meetings to inform team of program progress 

X 




P076 

PM solicits opinions from team members before making decisions 


X 



P077 

PM lets teams make decisions affecting their work 


X 



P078 

PM frequently makes decisions without any consultation with members 


X 
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2.b.1 

2.b.2 

2.b.3 

2.b.4 

P086 

PM sets communication protocol to be followed 




X 

P087 

PM allows unrestricted communications 


X 



P095 

PM facilitates horizontal communication within program 



X 


P096 

PM facilitates communication during integration 



X 


P097 

PM holds meetings without clear objectives listed prior to meeting 



X 


PI 04 

PM is readily willing to listen to program problems and complaints 


X 



P105 

PM takes action to resolve program problems and complaints 


X 



Pill 

Although individual’s tasks are specific, each exposed to the “bigger 
picture” 

X 





Table 3. Process Area Communication and Coordination 


3. Process Area Work Environment 

• Goal 2.C.1 : The physical environment and resources needed by the 
workforce to perform their assignments are made available. 

• Goal 2.C.2: Distractions in the work environment are minimized. 

• Goal 2.C.3: Work Environment practices are institutionalized to 
ensure they are performed as managed processes. 




2.C.1 

2.C.2 

2.C.3 

P047 

Management provides basic needs of office facilities fairly well / Office 
facilities are a drawback to working in the program 

X 



PI 04 

PM is readily willing to listen to program problems and complaints 


X 


P105 

PM takes action to resolve program problems and complaints 


X 


R004 

Risk management plan updated regularly 



X 

R005 

Risk Management is formal and documented / Risk Management is 
informal, if at all 



X 

R006 

Resource risks examined / No resource risks examined 



X 


Table 4. Process Area Work Environment 


4. Process Area Performance Management 

• Goal 2.d.1: Unit and individual performance objectives related to 
committed work are documented. 

• Goal 2.d.2: The performance of committed work is regularly 
discussed to identify actions that can improve it. 

• Goal 2.d.3: Performance problems are managed. 

• Goal 2.d.4: Outstanding performance is recognized or rewarded. 

• Goal 2.d.5: Performance Management practices are 

institutionalized to ensure they are performed as managed 
processes. 




2.d.1 

2.d.2 

2.d.3 

2.d.4 

2.d.5 
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2.d.1 

2.d.2 

2.d.3 

2.d.4 

2.d.5 

P008 

Consults with team members to find solutions to problems / Consults team 
members to get validation of program manager’s (PM) predetermined 
solution 



X 



P044 

Management welcomes problems as challenges and opportunities / 
Management views problems as obstacles and grounds for punishment 



X 



P045 

Team members participate in performance evaluations of peers / 

Personnel evaluations are strictly PM responsibility 


X 




P046 

Management reinforcement feedback sparse and inconsistent, if any / 
Management provides timely reinforcement feedback for positive 
behaviors 

X 

X 


X 

X 

P053 

Coders notebook, weekly accomplishment reports required / Not required 


X 

X 


X 

P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 





X 

P068 

Action items sometimes are not followed through / Action items 
communicated and followed thoroughly 





X 

P089 

PM takes control in difficult/problem areas 



X 



P112 

PM has clearly defined his/her expectations for each individual 

X 





P115 

PM attempts to motivate individuals on the program team 



X 



P119 

PM attempts to spotlight individuals in the program for positive exposure 




X 


E004 

Resource evaluations made for program / No resource evaluations for 
planning 

X 




X 

E005 

Estimates updated at reviews / Estimates constantly updates (in between 
reviews, too) 


X 



X 

E006 

Work breakdown structure has objective measure of completeness 

X 




X 


Table 5. Process Area Performance Management 


5. Process Area Training and Development 

• Goal 2.e.1: Individuals receive timely training that is needed to 
perform their assignments in accordance with the unit’s training 
plan 

• Goal 2.e.3: Training and Development practices are 
institutionalized to ensure they are performed as managed 
processes. 




2.e.1 

2.e.3 

P039 

Training is required and planned on a regular basis / Training is ad hoc 

X 

X 

P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 

X 


E007 

Training part of estimates/Training omitted in estimates 


X 


Table 6. Process Area Training and Development 


B. LEVEL 3: DEFINED 

1. Process Area Competency Analysis 

• Goal 3.a.1: The workforce competencies required to perform the 
organization’s business activities are defined and updated 

• Goal 3.a.2: The work processes used within each workforce 
competency are established and maintained 
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• Goal 3.a.3: The organization tracks its capability in each of its 
workforce competencies 

• Goal 3.a.4: Competency Analysis practices are institutionalized to 
ensure they are performed as defined organizational processes. 




3.a.1 

3.a.2 

3.a.3 

3. a. 4 

P024 

PM reacts to needs of the moment / Methodically follows plans 


X 



P035 

Formal team building procedures are used / No formal team building is 
emphasized 


X 



P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 

X 




P051 

Formal communication protocol / Informal communications 


X 



P053 

Coders notebook, weekly accomplishment reports required / Not required 



X 


P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 



X 


P069 

Team members require frequent clarifications by PM for assigned tasks / 
Team members rarely require clarifications by PM for assigned tasks 

X 




E001 

Work breakdown structure developed 





R003 

Personnel risks examined / No personnel risks examined 




X 

R004 

Risk management plan updated regularly 




X 

R005 

Risk Management is formal and documented / Risk Management is 
informal, if at all 




X 


Table 7. Process Area Competency Analysis 


2. Process Area Workforce Planning 

• Goal 3.b.3: Units perform workforce activities to satisfy current and 
strategic competency needs 

• Goal 3.b.4: Workforce Planning practices are institutionalized to 
ensure they are performed as defined organizational processes. 




3.b.3 

3.b.4 

P001 

Long range organizational vision / 

Short term program and immediate work focus 

X 


P017 

Program expectation not influenced by PM / Program expectation 
managed by PM 

X 


P039 

Training is required and planned on a regular basis / Training is ad hoc 

X 


P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 

X 


P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 


X 

P075 

PM regularly holds meetings to inform team of program progress 

X 

X 

P090 

PM looks ahead to new programs, new upgrades of existing program 

X 


E004 

Resource evaluations made for program / No resource evaluations for 
planning 


X 

E005 

Estimates updated at reviews / Estimates constantly updates (in between 
reviews, too) 


X 

E008 

Team possibilities considered for planning of program / no consideration 
for outside teaming possibilities 


X 


Table 8. Process Area Workforce Planning 
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3. Process Area Career Development 

• Goal 3.d.2: Individuals pursue career opportunities that increase 
the value of their knowledge, skills, and process abilities to the 
organization. 




3.d.2 

P041 

Consideration for team members’ career goals are reflected in 
assignments / Team members must adapt to tasks that are assigned 

X 

P074 

PM consults with each team member regarding their career goals 

X 

P082 

PM assists team members in developing / advising of career path 

X 

P119 

PM attempts to spotlight individuals in the program for positive exposure 

X 


Table 9. Process Area Career Development 


4. Process Area Workgroup Development 

• Goal 3.f.1: Workgroups are established to optimize the 

performance of interdependent work. 

• Goal 3.f.2: Workgroups tailor defined processes and roles for use in 
planning and performing their work. 

• Goal 3.f.3: Workgroup staffing activities focus on the assignment, 
development, and future deployment of the organization’s 
workforce competencies 

• Goal 3.f.4: Workgroup performance is managed against 

documented objectives for committed work. 

• Goal 3.f.5: Workgroup Development practices are institutionalized 
to ensure they are performed as defined organizational processes. 




3.f.1 

3.f.2 

3.f.3 

3.f.4 

3.f.5 

P017 

Program expectation not influenced by PM / Program expectation 
managed by PM 




X 

X 

P019 

PM waits and sees what happens then plans / Management plans far in 
advance 




X 


P034 

Program members have clearly defined, segmented roles / Work 
responsibilities are shared 


X 




P037 

Big picture conveyed to all team members by PM / PM focuses on the 
partitioned tasks with team 


X 




P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 


X 




P053 

Coders notebook, weekly accomplishment reports required / Not required 

X 



X 


P057 

PM and coder communication face to face / PM and coder communication 
primarily email 

X 





P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 

X 





P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 




X 


P067 

Work is seen as complex processes involving team working together / 

Work broken into pieces with minimal team member interaction 

X 





P095 

PM facilitates horizontal communication within program 


X 
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3.f.1 

3.f.2 

3.f.3 

3.f.4 

3.f.5 

P096 

PM facilitates communication during integration 


X 





Table 10. Process Area Workgroup Development 


5. Process Area Participatory Culture 

• Goal 3.g.1: Information about business activities and results is 
communicated throughout the organization 

• Goal 3.g.2: Decisions are delegated to an appropriate level of the 
organization 

• Goal 3.g.3: Individuals and workgroups participate in structured 
decision-making processes 

• Goal 3.g.4: Participatory Culture practices are institutionalized to 
ensure they are performed as defined organizational processes. 




3.g.1 

3.g.2 

3.g.3 

3.g.4 

P002 

Lead through personal attention to others / Action-oriented leadership 
approach 

X 




P003 

Run as much of the organization as possible / let team make decisions as 
much as possible 


X 



P004 

Direct and domineering style / 

Encourage independence of others 



X 


P008 

Consults with team members to find solutions to problems / Consults team 
members to get validation of program manager’s (PM) predetermined 
solution 



X 


P009 

Keep people well informed / Only as much knowledge as necessary for 
their work 

X 




P012 

Leadership, management decisions exclusively by PM / PM makes 
decisions but gets inputs from team 


X 

X 


P013 

Team-program manager relationship adult-adult / Team-PM relationship 
parent-child 


X 



POM 

PM makes decisions but gets inputs from team / All program team 
members responsible for program decisions 



X 


P021 

Facilitative approach to solving problems / Take charge readily and often 


X 



P037 

Big picture conveyed to all team members by PM / PM focuses on the 
partitioned tasks with team 

X 




P040 

Each team member is educated on and understands overall program and 
their roles / Team members only know their respective areas 

X 




P042 

Team members assignments and responsibilities are mostly dictated by 

PM / Assignments and responsibilities are discussed and agreed upon with 
PM 



X 


P043 

Management leads in problem solving / Management facilitates and lets 
team lead in problem solving 


X 

X 


P054 

User-coder relationship established, encouraged, and mediated / User- 
coder interaction minimized 

X 




P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 

X 



X 

P059 

Open communications is encouraged / Communication through chain of 
command only is encouraged 

X 




P062 

Management regularly holds team meetings / Meetings are sporadic 

X 



X 

P065 

Team-PM relationship adult-adult / Team-PM relationship parent-child 


X 

X 


P075 

PM regularly holds meetings to inform team of program progress 

X 



X 

P077 

PM lets teams make decisions affecting their work 


X 
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3.g.1 

3.g.2 

3.g.3 

3.g.4 

P078 

PM frequently makes decisions without any consultation with members 



X 


P095 

PM facilitates horizontal communication within program 

X 




P096 

PM facilitates communication during integration 

X 




P098 

PM must approve all decisions within the program 



X 


P109 

PM directs what needs to be done and directs how to do it 



X 


P112 

PM has clearly defined his/her expectations for each individual 

X 




P118 

PM directs what needs to be done, but does not direct how 


X 




Table 11. Process Area Participatory Culture 


C. LEVEL 4: PREDICTABLE 

1. Process Area Empowered Workgroups 

• Goal 4.b.1: Empowered workgroups are delegated responsibility 
and authority over their work processes. 

• Goal 4.b.2: The organization’s workforce practices and activities 
encourage and support the development and performance of 
empowered workgroups. 

• Goal 4.b.3: Empowered workgroups perform selected workforce 
practices internally 

• Goal 4.b.4: Empowered Workgroup practices are institutionalized to 
ensure they are performed as defined organizational processes. 




4.b.1 

4b.2 

4.b.3 

4.b.4 

P003 

Run as much of the organization as possible / let team make decisions as 
much as possible 



X 


P004 

Direct and domineering style / 

Encourage independence of others 

X 




P007 

Act strongly and forcefully in the field of ideas / Prefer to lead other 
independent types while seeking autonomy for self 



X 


P009 

Keep people well informed / Only as much knowledge as necessary for 
their work 


X 



P011 

Manage others loosely and prefer minimal supervision / Follow traditional 
procedures and rules conscientiously 



X 


P021 

Facilitative approach to solving problems / Take charge readily and often 

X 




P043 

Management leads in problem solving / Management facilitates and lets 
team lead in problem solving 



X 


P077 

PM lets teams make decisions affecting their work 

X 




P078 

PM frequently makes decisions without any consultation with members 

X 




P098 

PM must approve all decisions within the program 

X 




P112 

PM has clearly defined his/her expectations for each individual 

X 




P117 

PM directs how he/she expects the task to be accomplished 

X 




P118 

PM directs what needs to be done, but does not direct how 

X 




E001 

Work breakdown structure developed 




X 

E003 

Develop work breakdown structure / Assign work as needs arise 




X 


Table 12. Process Area Empowered Workgroups 


2. 


Process Area Quantitative Performance Management 
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• Goal 4.d.1: Measurable performance objectives are established for 
competency-based processes that most contribute to achieving 
performance objectives 

• Goal 4.d.2: The performance of competency-based processes is 
managed quantitatively 

• Goal 4.d.3: Quantitative Performance Management practices are 
institutionalized to ensure they are performed as defined 
organizational processes 




4.d.1 

4.d.2 

4.d.3 

P017 

Program expectation not influenced by PM / Program expectation 
managed by PM 


X 


P045 

Team members participate in performance evaluations of peers / 

Personnel evaluations are strictly PM responsibility 


X 


P046 

Management reinforcement feedback sparse and inconsistent, if any / 
Management provides timely reinforcement feedback for positive 
behaviors 


X 


P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 



X 

P066 

Schedules are spontaneous and poorly communicated / Schedules must 
be fixed and rigidly followed and formally reported 

X 


X 

P083 

PM empowers program members to recommend hiring new team 
members 


X 


P110 

Program personnel have clearly defined specific tasks 

X 



P112 

PM has clearly defined his/her expectations for each individual 

X 



E002 

Task estimated with realistic expectations of productivity probabilities 

X 



E005 

Estimates updated at reviews / Estimates constantly updates (in between 
reviews, too) 



X 

E006 

Work breakdown structure has objective measure of completeness 

X 




Table 13. Process Area Performance Management 


D. LEVEL 5: OPTIMIZING 

1. Process Area Continuous Capability Improvement 

• Goal 5.a.3: Workgroups continuously improve the capability of their 
workgroup’s operating processes. 

• Goal 5.a.4: The capabilities of competency-based processes are 
continuously improved. 

• Goal 5.a.5: Continuous Capability Improvement practices are 
institutionalized to ensure they are performed as defined 
organizational processes. 




5.a.3 

5.a.4 

5.a.5 

P001 

Long range organizational vision / 

Short term program and immediate work focus 

X 



P025 

PM has technical experience particular to the particular s/w program / PM 
relies on team members solely 


X 


P026 

PM participates in technical reviews / PM only in non-technical reviews 


X 


P027 

PM participates in making technical decisions when problems arise / PM 
delegates technical questions 


X 
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5.a.3 

5.a.4 

5.a.5 

P028 

PM does not get involved discussing technical options / PM contributes to 
technical options when discussed 


X 


P029 

PM does not review technical options and decisions / PM reviews technical 
options and decisions 


X 


P030 

PM actively attempts to keep up-to-date with current technology and 
standards / PM is removed from cutting edge technology issues 


X 


P031 

PM receives technical periodicals and occasionally references applicable 
articles / PM doesn’t read periodicals nor references current articles to 
team 


X 


P032 

PM doesn’t have technical background (or education) / PM has technical 
background (or education) 


X 


P058 

Program team updated regularly regarding organizational & program 
status / Meetings infrequently scheduled 

X 



P090 

PM looks ahead to new programs, new upgrades of existing program 


X 


PI 04 

PM is readily willing to listen to program problems and complaints 


X 


P105 

PM takes action to resolve program problems and complaints 


X 


Table 14. Process Area Continuous Capability 1 

improvement 


2. Process Area Organizational Performance Alignment 

• Goal 5.b.1: The alignment of performance among individuals, 
workgroups, units and the organization is continuously improved. 

• Goal 5.b.2: The impact of workforce practices and activities on 
aligning individual, workgroup, unit, and organizational performance 
is continuously improved. 

• Goal 5.b.3: Organizational Performance Alignment practices are 
institutionalized to ensure they are performed as defined 
organizational processes 




5.b.1 

5.b.2 

5.b.3 

P045 

Team members participate in performance evaluations of peers / 

Personnel evaluations are strictly PM responsibility 

X 



P046 

Management reinforcement feedback sparse and inconsistent, if any / 
Management provides timely reinforcement feedback for positive 
behaviors 

X 



P115 

PM attempts to motivate individuals on the program team 

X 



E001 

Work breakdown structure developed 

X 


X 

E003 

Develop work breakdown structure / Assign work as needs arise 

X 

X 

X 

E005 

Estimates updated at reviews / Estimates constantly updates (in between 
reviews, too) 


X 


E006 

Work breakdown structure has objective measure of completeness 


X 

X 


Table 15. Process Area Organizational Performance Alignment 


3. Process Area Continuous Workforce innovation 

• Goal 5.C.2: Innovative or improved workforce practices and 

technologies are identified and evaluated. 

• Goal 5.C.3: Innovative or improved workforce practices and 

technologies are deployed using orderly procedures 
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• Goal 5.C.4: Continuous Workforce Innovation practices are 
institutionalized to ensure they are performed as defined 
organizational practices. 




5.C.2 

5.C.3 

5.C.4 

P030 

PM actively attempts to keep up-to-date with current technology and 
standards / PM is removed from cutting edge technology issues 

X 



P031 

PM receives technical periodicals and occasionally references applicable 
articles / PM doesn’t read periodicals nor references current articles to 
team 

X 



P060 

Program manager is accessible for discussions / Program manager difficult 
to get an appointment to see 

X 



P079 

PM understands the technology/language of the program 

X 



P080 

PM is able to communicate with others the technical issues of the program 

X 



PI 04 

PM is readily willing to listen to program problems and complaints 

X 



P039 

Training is required and planned on a regular basis / Training is ad hoc 


X 

X 


Table 16. Process Area Continuous Workforce Innovation 

D. QUESTIONS WITHOUT CORRELATION TO P-CMM 


No. 

Questions of the Quality Management Metric 

P005 

Traditional leaders respect hierarchy / Do what needs to be done 

P006 

Win cooperation rather than demand it/ 

Tough-minded with others 

P015 

When a problem arises: management takes over to solve it / Management 
lets the team solve the problems 

P016 

Leadership is do as 1 say, not do as 1 do / Leadership by example 

P018 

PM gives freedom to team, but does has no mentoring for leaders / PM 
empowers teams by mentoring members to be leaders 

P022 

PM is complex, takes much time to understand / Management is simple, 
easy to figure out 

P023 

PM prefers to plunge right in / Takes time to separate things to be done 
and order of doing them 

P033 

Team members avoid PM when they need technical advice / Team 
members generally consider talking to PM regarding technical issues 

P036 

Program manager flexible regarding work hours / Program manager 
maintains strict standards for work hours 

P052 

External vertical communications restricted / External vertical 
communication allowed 

P081 

PM prioritizes problems or conflicts within the program 

P085 

PM specifically assigns work to each program member 

P088 

PM readily makes tough decisions 

P091 

PM maintains regular communications with all stakeholders 

P092 

PM maintains regular communications with users 

P093 

PM encourages program team communication with users 

P094 

PM encourages program team communication with stakeholders 

P099 

PM must approve all interactions with stakeholders 

P100 

PM must approve all interactions with users 

P101 

PM makes all presentations to stakeholders / users 

PI 02 

PM is considered “flexible” in terms of program members personal issues 

PI 03 

PM, at least occasionally, schedules/promotes outside work team activities 

P106 

PM is generally respected by stakeholders, users, and organization 

P107 

PM sometimes fails to grasp important technical issues in program 

P113 

PM delegation of duties is usually seamless in execution 
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No. 

Questions of the Quality Management Metric 

P114 

PM acts as facilitator to solving personnel conflicts 

P116 

PM clearly separates technical from managerial roles for individuals 


Table 17. Questions without correlation to P-CMM 
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